中島@ブレーンです。
 
> 関係者です。

直々にコメントをいただけるとは! ありがとうございます。

# 自分が手さぐりでやっていたこと(に多少なりとも近くて、さらに先を行って
# いること)を、きちんと整理して定式化していただけたので、あの論文は私に
# とってはすごくありがたかったです。自分でもメリット・デメリットを整理で
# きてきたし、Walrusの実装を人に説明する時も、あの論文のおかげで楽ができ
# ると思います。

> > 例えば、親クラスPと子クラスCがあったとします。両者に何かメソッドを追加す
> > る場合、Pを継承してP2、Cを継承してC2を作成し、P2,C2に新しいメソッドを追
> > 加することになります。
> > 
> >   P  →  C                  →: is-a関係を表現する継承
> >  ↓     ↓                  ↓: 差分を実装するための継承
> >  P2     C2         
> > 
> > この図の↓で表わされている関係を別のメカニズムで表現しようと言うのが、
> > "差分モジュール"という考え方だと思います。
> 
> 普通の継承でやると、既存のコードの中に埋め込まれている P や C への参照
> で問題が発生するんですよねぇ。普通の OOP では factory method でどうに
> かするんでしょうが。
> 
> # Ruby だとあまり問題になりませんが、静的な型を持っている言語の場合に
> # は P2 が C2 の祖先でないことも問題になります。

私はkind_of?を多用していたので、P2がC2の祖先でないことも実際に問題でした。
それも"差分モジュール"もどきを使った理由のひとつです。

モデル構築におけるis-a関係を表現するための仕様の継承と、実装を共有する手
段としての継承を区別、整理することは重要だと思います。その点からも"差分
モジュール"という考え方には魅力があると思います。

> > 上記のもどき手法で、複雑な差分モジュールの継承関係(ダイヤモンド継承)も可
> > 能だと思いますが、名前の衝突が起きると悲惨なバグになります。
> 
> まつもとさんがたまに話に出す、selector namespace の話が実現されると、
> どうにかなるんじゃないですかね。たぶん。

selector namespaceってそういうことだったんですね。ようやく少し理解できま
した。これは他にも応用範囲が広いし、Rubyらしいと思います。実現したらうれ
しいですね。

> > ・ Rubyでこのような"差分モジュール"を使っている例は他にありますか?

> ちょっと lib 以下を grep class すると、complex.rb が似通ったことをして
> ますね。Numeric 以下のクラスを複素数として扱えるようにするメソッドを追
> 加しています。

そう言われて見てみたら、jcode.rbも似たことをしてますね。たださんもおっしゃっ
てますが、Rubyでは案外自然な手法かもしれませんね。

> > ・ 名前の衝突を避けるよい方法はないでしょうか?
> 
> 現時点では、確実なのは prefix をつけるしかないんじゃないでしょうか。
> 
> 充分に適切な名前をつければ衝突する可能性はかなり低いと思うんですが、確
> 実とはいえませんからねぇ。

そうですね。多少のリスクはあっても、名前にこだわることで対応するのが
Rubyらしいような気もします。メソッドの名前をちゃんと命名していれば、意図
しない名前の衝突は実際上問題にならないほど減らせるかもしれませんね。

> > ・ 実行時コスト的な観点から、不要なメソッドを大量にloadする負荷について
> >    どうなのか?
> 
> 全部 load せずに(個々のアプリケーションについて)必要な奴だけ require
> すればむしろ load することになるもの減るのでは?

これは説明不足でした。"差分モジュール"方式でひとつのclassの定義を機能別
にファイルに分割した方が、classの定義を1ファイルにまとめるより、実行時コ
ストが小さいのは当然です。

私が言いたかったのは、「実行時コストの差が"差分モジュール"方式を採用する
(ひとつの)理由となるほど意味があることなのかどうか」ということです。

そしてこれを書きながら「"差分モジュール"方式は苦しまぎれの変則的なテクニッ
クで王道とは言えないからできれば避けたい。使うなら何らかの言い訳がほしい」
というような感覚が自分の中にあることに気がつきました。

そんな卑屈にならずに堂々と使っちゃっていいんですね(笑)

-- 
「stableでなければ生きていけない。unstableでなければ生きてる意味がない」
中島 拓 (株)ブレーン 研究部 (tnakajima / brain-tokyo.jp)
http://www.brain-tokyo.jp/~research/koutetu/