requestsがバリバリ供給されてくるのでもう少し中身を知っておきたいと思って公式ドキュメントを拾い読みしたりしたメモと所感。ドキュメントではStripe社内の実態の話がちょいちょい出てくるのと、Ruby3との関わりあたりが興味深かった。Sorbet関連のプロジェクトを少し触ってみてパッチを送ってみる過程でも型をブッ込んだプロジェクトってこんな感じなのか〜と思うところがあった。Sorbet型の恩恵を受けるためだけにすでに存在している巨大なコードベースをrewriteしたり、言語が持つ大きな資産を捨てて別言語に乗り換えるのは現実的ではない。Rubyにはものすごい量と質の資産がある。既存資産と型の恩恵の両方を活かすにはTypeScriptが実践して成功を収めたような漸進的型付けが有効となる。Sorbetでは妥協点として、メソッド呼び出し・メソッド定義・クラス・ファイルそれぞれの単位で型検査をオプトアウトできるようにした。T.untypedSorbetの型システムにおける型の一つ。漸進的型付けという観点でいえばもっとも重要な型。T.untyped型であることを主張することができるまた、T.untyped型のすべての値は他の型であることを主張することができる型付けを始めたタイミングではほぼすべてがuntypedである漸進的型付けに短期的には役立つが長期的にはなくしていく型。Sorbetファイルの先頭に記述するマジックコメントのこと。tcの型検査のレポート内容を5段階に分けることができる。TypeScriptでstrictnessを調整できるのに似ている。trueないしstrictあたりが目指すところ。falsesyntax、定数名の解決、sigの正しさのみレポートされる。Sorbetsigによりシグネチャが付与されたメソッド呼び出しはラップされ、前後で以下を検査される。宣言にマッチする引数で呼び出されたか結果が宣言された戻り値にマッチするかsigが間違っていたらリファクタリング対象の検出はできない。到達できるコードに到達できないとSorbetは判断してしまうことがある。将来的には型情報を利用したRubyの高速化もありえるが、誤った型情報はそのために使えないし、sigで嘘をつくと実際には遅くなることも十分ある。checkをするかエコシステム含めてだいぶ参考にしているであろうTypeScriptとの大きな違いの1つがここだと思うので気になっていた。checkを重視するのは以下のため:型注釈に信頼が増す自動テストが型注釈のテストになるステージングや本番での型検査結果をモニタリングすることにより間違った型がコードベース全体に伝播する前に早期に検出できる型を付けたコードを型のないコードから守り、型の採用や型付けを促進する型注釈と実装の一致をランタイムで検証することで乖離を防ぎ、結果として型の恩恵を受けやすくして型付けのインセンティブを増やす、という戦略のようだ。error発生時にはロギングするだけ、などの制御が可能。T::Array[String]).void.on_failure(:log)}のように定義することもできる。.checked実行時に型検査するかどうかを選べる。これを多用するとそもそもランタイムでやる意義が薄れるので推奨はしていないようす。T::Array[String]).void.checked(:never)}型定義ファイルインラインでRubyファイルに型を書くこともできるがRBIファイル.rbiにも記述できる。文法上はRubyと全く同じように記述でき、メソッドの中身が空なだけ。Cで書かれたライブラリに型を与えるためにもこの仕様は必要。ライブラリの型を置くことができる。Sorbetではない。標準ライブラリの型定義を用意するのはとても大事。現在、Sorbetが標準ライブラリの型定義を持っているおかげで、ユーザーがSorbetを使い始めた瞬間にメソッド呼び出しのうち約25%が型情報を持つほどのカバレッジになる。RBSの生成にはSorbetのRBIが使われるはずだし、Ruby本体が型定義のRBSを持つことでSorbetにもメリットがある。Playground雰囲気はわかるがリアルワールドの例が見たくなった。sigilのレベルを引き上げたり、ライブラリのコードを読みつつsigを書いてみることでだいぶ理解が深まる。-aにより推論されたシグネチャを自動付与したり、生成された定義を見てみるのも面白い。requestを送れて一石二鳥。Sorbet本体を触るSorbet本体でも標準ライブラリの型定義が一部足りなかったりする。C++で書かれていたりビルド・テストツールにBazelを使っていたりとRubyist的にあまり馴染みがないところもあるが.rbiに定義を足したりテストしたりするのはRubyでもなんとかなりそうだったのでちょっとしたパッチを送ってみた。github.com最初のビルドには30分かかった。所感TypeScriptを時折書いている身としては型注釈を書く体験自体に違和感はなかった。書きたいわけじゃないけど書いてるプロジェクトに入ったなら普通に書ける、みたいな。strictレベルで戦っていける感じはまだしていない。Vonageのgemを読んでいて思ったのはcontributionのハードルを下げてくれるということ。ライブラリのコードを読むうえで実装者の意図がわかる静的検査、テストでの実行時型検査でしょぼいミスを防げるStripe社内でもこんな感じらしいのでライブラリに限らず、ではあるがOSSプロジェクト的にも嬉しいポイントではありそう。checkで受けられる恩恵の本質は実際にSorbetを導入したプロジェクトを運用してみないとなんともいえないかも。*2:TypeScriptの場合はランタイムがJSなので、JSでできないことはできないという制約は別途あるが...。checkのライブラリがあるけどメインストリームとはいえないと思うのでスルー。AdminにはExporterという機能がある。5はてなブログをはじめよう!ohbaryeさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。