不親切だった年末のエントリの続き。
OOPSLAの論文(Java版)と2003年の論文(Smalltalk版)を読む。
Classboxは一種のパッケージ(ネームスペース)で、 importで取り込んだクラスに対して自分のパッケージ内だけで有効な修正(refine)を行うことを許す、 というものだ。一種のpartial class(複数のファイルに分散してクラスを定義する)とか open class(あるクラスに対して追加で定義を変更できる)に似ているが、 重要な違いはrefineによって加えた修正の有効範囲はそのClassboxにレキシカルに限定されるということ。
Rubyに関連して具体的な例を出すと、 たとえばjcode.rbのようStringクラスのメソッドを置き換えちゃうようなClassboxを作ったとすると、 そのメソッド置き換えはjcode.rbが提供するClassbox(と、それをimportしたClassbox)でだけ有効で その外には影響を与えないってこと。同じことはmathn.rbにも言える。
これらのライブラリは、グローバルにクラスの振る舞いを変えちゃうので嫌われているんだけど、 Classboxに限定した範囲内でだけ有効だったら、そんなに気にしないで既存のクラスをがんがん変更しても 悪影響は与えないってこと。
Rubyのopen classは非常に便利なんだけど、 グローバルな影響が大きいというデメリットもあった。
Classboxのようなやり方であれば、影響範囲を制御できる。 できることならば、このような機能を将来のRubyに取り込みたい。 何回考えても挙動が理解できなかったselector namespaceと違って、 Classboxは即座にピンと来た。これこそが進む道だと思う。
ただ、Classbox(Smalltalk版)やClassbox/J(Java版)の仕様をそのまま Rubyに持ってこれるかっていうとなかなか難しい。 Javaと違ってRubyのクラスはオブジェクトだし、 インナークラスも外からまる見えだし。
APIも実装も事前に十分に検討する必要があるだろう。
....、論文ネタになるかな。無理かな。
Smalltalk版はインタプリタそのものをいじって、メソッド呼び出しのコストが1.2倍程度らしい。 Java版はプリプロセッサを使っているのだが(だから仕様としては結局はC#のpartial classと同じ)、 ナイーブな実装のためかメソッド呼び出しが25倍遅いらしい。これは痛い。
Rubyの場合、インタプリタを直接いじれば、(今の実装ならば)グローバルメソッドキャッシュが効いて それほど遅くならずにすむのではないだろうか。ただ、クラスの参照がインダイレクトになるのが どの程度影響するのかはやってみないと事前に見積もるのは難しいだろうなあ。
しばらく前に試してたselector namespaceとそう大きく違わないようがきがしますが。
selector namespaceに対するイメージのほうが違う?
たぶん、そうなんでしょう。
ただ、こっちは挙動やら実装のイメージやらがえらく具体的に私の心に響いたってことです。