動的型解析器 Ethotrace

Transcript

1. 動的型解析器 Ethotrace テストはすでに型を知っている すぎうり
2. 自己紹介　すぎうり • Twitter:@uproad3 • Ruby歴20年 • VRChat歴7年 • 仕事：Rails | AWS | LT芸人 • 趣味：アーキテクト | リファクタリング | 電子工作 • 言語：Ruby | C# | C | JS | ほかいろいろ • 技術：Terraform | Unity | Ubuntu | MySQL | RaspberryPi • 悲しきフルスタックエンジニア • 最近はClaudeをシバきまわしている • 特に型に強い思い入れがあるわけではない
3. 第1章 型注釈 強制されてませんか ? TypeScript / Java / C# / Rust …　型を書かないとコンパイルが通らない Rubyには、それがない。 ——自由だ。
4. 第1章 Rubyには型注釈がない＝自由 型注釈を書かなくていい。書いてすぐ動く。 ダックタイピング ——「each できれば何でもいい」 # 型注釈なしでも動く def process(items) items.each { |x| puts x } end process([1, 2, 3]) # OK process("hello") # OK （each を持てば何でも） この自由さがRubyの良さ——でも、代償がある
5. 第1章 でも、その自由の代償に —— def process(x) String Array Enumable IO 結局 何を渡せばいいのか？ 何が返ってくるのか？ 型注釈もドキュメントもない。 コードを上から下まで追うしかない。 String Array
6. 第1章 見えないものは、 3つある def process(x) ① 引数 何を渡せばいい? ② 投げる例外 何がraiseしうる? ③ 外部依存 裏で何に触ってる? インターフェースが見えないから ——使い方がわからない ④ 戻り値 何が返ってくる？
7. 第1章 "書けば"解決する。でも —— 型注釈を書けば解決する # sig { params(x: T.untyped) # .returns(String) } def process(x) ... end RBS / Sorbet でも—— ・書くコストが高い ・既存コードへの後付けは重い ・メタプロと相性が悪い 書かずに、型情報を手に入れる方法はないか ?　——テストがすでに証拠を持っている
8. 2章　型は"書く"のではなく "観測する" 「書く」 RBS / Sorbet 人がコードを読んで宣言する 書くコストがかかる 後付けは重い 書くコストなしには型情報が得られない 「観測する」 ethotrace テストを走らせて記録する 書かなくていい テストがあれば証拠はある テストを走らせるだけで型情報が手に入る
9. 第2章 型には、3つの側面がある Effect-TS の Effect<Success, Error, Requirements> という捉え方を借りた （詳しいのはそのへんにいるんで後で聞いてください） Success 成功して何を返すか Error どんな失敗をしうるか Requirements 何を必要とするか 型は「引数」と「戻り値」だけじゃない ——テストで観測すればこの 3つが採れる
10. 第2章 この"観測する手段 "、昔から持っていた eavesdrop_call——大学時代のリファクタリング研究で作ったツール テストの網羅性を測るために、prepend でメソッド呼び出しを盗み聞きしていた 当時の目的は「網羅性」——型のことは1ミリも考えていなかった Effect-TSの3側面を知って気づいた —— 網羅性のために覗いていたメソッド呼び出しは、型情報そのものだった
11. 第2章 観察するように観測する この観測するアプローチ、名前どうしようとClaudeに相談したら—— ethogram　動物行動学の用語。動物の振る舞いを観察して記録したカタログ Rubyのオブジェクトを「観察対象の動物」と見立て、振る舞いを記録する etho（振る舞い）＋trace（追跡）＝ ethotrace 型を"書く"んじゃない。動物を観察するように、 "観測して"手に入れる
12. 第3章 2章で借りた 3側面、Rubyで観測するとこうなる 受け付けるもの / 返すもの 引数に何のメソッドが 呼ばれたか 何をreturnしたか 投げる例外 外に飛んでいった 例外クラス 外部依存 ENV / Time / IO … に触れたか
13. 第3章 "何を受け付けるの ?"——第1章の問いへの答え 第1章の「このメソッド、結局何を受け付けるの?」 観測すると、答えが出ます 「each、map、size が呼ばれた」という事実が記録される 型名ではなく「呼ばれたメソッドの集合」 ——ダックタイピングの側面から見た最低限必要な型 「each できれば何でもいい、の'何でも'に輪郭がつく」
14. 第3章 prepend で、メソッド呼び出しを捕まえる module ArgumentTracer def process(x) # 引数に呼ばれたメソッドを記録 called = detect_protocol(x) # x に何が呼ばれるか観測 $observations << { method: :process, args_protocol: called } super # 元のメソッドを呼ぶ end end MyClass.prepend(ArgumentTracer) 詳しくはリポジトリで： github.com/uproad/ethotrace
15. 第3章 観測結果——引数プロトコル 整形後の観測結果（実際の出力を読みやすく表示） method: MyClass#process args: x → protocol: [:each, :map, :size] # xに呼ばれたメソッドの集合 # = "each、map、sizeを持っていれば何でも渡せる " 「型名」ではなく「呼ばれたメソッド集合」 ——これがダックタイピングの型の実体
16. 第3章 このメソッドは例外を投げうるか prepend の rescue で、外に飛んだ例外を捕まえる module ExceptionTracer def process(x) super rescue => e # 外に飛んだ例外クラスを記録 $observations << { raised: e.class } raise # 再度投げる end end 「型注釈には載らない情報」 ——呼び出し元が何を rescueすべきか、観測が教えてくれる
17. 第3章 観測結果——例外チャネル method: MyClass#process raised: - ArgumentError - Tax::RateError # このメソッドはこれらを投げ "うる" 型注釈には普通載らない情報。 でも、呼び出し元はこれを知りたい ——何を rescue すべきかが分かる
18. 第3章 もうひとつ ——外部依存も見える method: MyClass#process requirements: - time.read # Time.now を呼んだ - env.read(KEY) # ENV['KEY'] を参照した # requirements が空 = 純粋なメソッド ENV・Time・IO に触れたか——「純粋かどうか」が分かる
19. まとめ ダックタイピングは自由、でも「何を受け付けるか」が見えなかった テストを走らせれば、その振る舞いは観測できる 受け付けるもの、返ってくるもの、投げる例外、外部依存 観察すれば見えてくる Rubyでは、振る舞いベースの型観測ができる
20. 型は"書く"だけのものじゃない 静的型付け言語では型は「書かされるもの」。 でもRubyでは——書かなくても、テストがすでに証拠を持っている。 観察するように、観測して手に入れる。 ——こういう発想も、あるんですよ。 → https://github.com/uproad/ethotrace