昔話からdRubyの過程でメタプログラミングしてる話をします。
- 私は旧いスタイルのUNIXプログラミングに慣れていました。
- 単機能のデーモンをいろいろなIPCをつないで協調させる世界です。
- fork/pipe/signal
- SysV IPC (shared memory, message, semaphore)
- さまざなアーキテクチャ
- 1992頃socketとselectを、その後にCGIを知りました
- さまざなIPCをCGIに切り替えて遊んでいました。
- Perl/C/AppleScript
- request/response, stateless
- 1999、Rubyとshttpsrv（Ruby製の小さなWebサーバ）を知りました。
- WEBrickのずっと前。非常にシンプル。
- アプリケーションプロセスとWebインターフェイスを一つに
- X11みたい
- PerlのCGIの代わりにRubyと極小のWebサーバ
- Rubyで書かれたアプリケーション（サービス）をhttpで相互につなぐ
- 状態をもつ極小のWebサーバはすごく楽しい
- (稚拙な) WebAPI
- Rubyで書かれたメソッドをhttpで包んでる
- メソッドコールをRPCへ（関数コール／API化）
- プロトコルの設計、オブジェクトのシリアライズに費やされる
- コード書くのも面倒だけど、そういうレイヤーが厚いのが気に入らない
- Rubyの世界をhttpの世界に翻訳するのは不自由な点が多い
- インピーダンスミスマッチ（注: 英語でもこんなこというの？）
- 中間の変換を省こう
- Rubyのメソッド呼び出しそのものをソケットの上に拡張しよう
- Rubyのソケットプログラミングの定石はshttpsrvから学んだ
- 道具は揃ってる
- Rubyで書かれたメソッドならRubyで呼ぼう — より直接的にRPCからRMIへ
- Rubyのような分散オブジェクトを!
- メタプログラミングって聞いたのはずいぶん経ってから
- プロキシオブジェクトはリモートのオブジェクトの代替である
- まるで普通の（いつもの）オブジェクトであるかのように振る舞う偽物が必要
- なにかのラッパーやシンタックスシュガーではない
- メタプログラミングしなければ意味がない
- method_missing
- Marshal
- ObjectSpace._id2ref
- 未知のメソッドに反応するメソッド
- プロキシオブジェクト（DRbObject）はmethod_missingを捕まえてリモートに転送する
- オブジェクトをシリアライズする
- Rubyのオブジェクトはたいていシリアライズ可能
- File, Thread, Procなどは例外があがる
- シリアライズできないものはDRbObjectで包んでシリアライズする
- オブジェクトの参照をコピーする
- オブジェクトのidからオブジェクトに変換する
- プロキシオブジェクトはサーバー（DRbServer）の位置と対応するオブジェクトのidを覚えている
- メソッドを転送するとき、このidをつける
- DRbServerはidからオブジェクトを見つけて、そのメソッドをコールする
- ブロック付きメソッドを真似たコールの工夫
- 未知のオブジェクトを復元するときの工夫
- dRubyは旧いUNIXプログラミングから始まって、httpのRPCを経由して今の形態になった
- dRubyはRMIを実現するために、メタプログラミングが必須となった
- dRubyで使用するメタプログラミングのテクニックを紹介した
デモが先かもしれません。