.NET上のPython処理系IronPythonがとうとう公開された。 オレゴン州ポートランドで開催中のOSCON 2004にあわせての公開らしい。
で、さっそくソースを読んでみるが、大変読みにくい。 C#に慣れてないってのもあるけど、 C#のリフレクションとIronPythonのリフレクションとが渾然一体となっていて 区別が付けにくいのがつらいところだ。
どうやら、メソッドは生成したILのコードをdelegateとして保持しておいて、 それを直接呼び出しているらしい。だから、メソッド呼び出しは、
という手順のようだ。確かに呼び出しにはリフレクションを使っていないが、 これで速いんだろうか。まあ、もともとのCPythonのセマンティクスも同じようなものなんで、 大丈夫なのかな。
そういえば、Jythonのソースは読んでないな(Java嫌い)。
LL Weekendが近づいているので、私の担当分Language Updateについてまとめようとするが、 今年(去年のLLから最近まで)は、言語仕様については進歩があんまりないことに気がついた。
一体、私はこの１年なにをしてたんだ(日記を書いてました)。
しかたがない、あと10日ほどの間にでっち上げるのはどうだろう。作者の強み。
国際化(M17N)の1.9への取り込み
どうせこの夏、論文に書くために、再実装＋1.9へのマージを予定していたので、前倒しする、とか。
メソッドコンビネーション
こっちは完全な新機能なので互換性の問題はない。が、効率の良い実装が大変なんだよねえ。 で、前田くんと議論したが...その結果は後で。
やっぱ無理があるかな。
というわけで、メソッドコンビネーションだ。
メソッドコンビネーションは、メソッドの前と後ろにフックをかけることを許すものだ。 CLOSで提供されている機能で、 一種のアスペクト指向と呼んでもよいかも。 というか、AspectJのGregor Kiczalesは元々CLOSのデザイナーでもあるから、 メソッドコンビネーションなどから発展してアスペクト指向が生まれたと言うべきだろうな。
これの効率の良い実装は難しい。 現在のRubyの実装を大きく変えないですむと嬉しい、という条件をつけるとなおさらだ。
思いついたのは(だれでも思いつきそうだが)、CLOSのメソッドコンビネーションが
という順序になっているのを、
という順序の変更を考えてみた。 CLOSとは確かに違うが、別にまったく同じであることにこだわるほど、CLOSに忠誠を誓っているわけではない。
とはいえ、primaryメソッドでsuperが呼ばれなければ、beforeメソッドやafterメソッドが一切呼ばれない点は、 嬉しくないこともあるだろう。すぐに考えついたのは、たとえばロギング機能をこれで実装しようとしたら、 includeでは(beforeメソッドなどは明示的にsuperを使わないと呼ばれないので)役に立たないと言う点だ。
これはincludeが(仮想的な)スーパークラスを追加するものだからいけないわけだ。 たとえばSatherのようなcode inlcusionであれば、同じレベルなので問題はない。 とはいえ、いまさらincludeの意味を変えるわけにはいかないので、 新しいオペレーション(かmoduleのような別物)を導入する必要があるなあ....。
などと、次々と考えが発散するのであった。でも、上記のアイディアはけっこう魅力的だなあ。 問題は「新しいオペレーション」の名前だな。ほんとはincludeが最適だと思うけど、 これは変えられそうにないし、「埋め込み」とかを意味する単語だといいのかな。
前田くんは「expand」を提案していた。include, extend, expand...、 うーん、一度慣れてしまえば、それなりにいいかも。