えー、Mix-in評論家のまつもとです。今日はshudoさんからコメントをいただきました。
mix-inの由来はともかく、次の2点がひっかかりました:
- C++にmix-inクラスがある。
- そういったmix-inクラスは、C#のinterfaceと同様の役割を果たす。
1.については、ここでは、多重継承を使って実装を差し込むことをmix-inと呼んでいるのかな？と想像してます。そういう流儀があるんでしょうか。 2.が言わんとすることは、なかなかわかりませんでした。ようやく気づいたことは「ここでは、実装(メソッド)の付加ではなくて、役割(interfaceも可)の付加をmix-inと呼んでいる」ということです。これをmix-inと呼ぶのは、どうなんでしょう？
まず、(1)ですが、元々Mix-inという用語が生まれたのはLispのオブジェクトシステムである Flavorsで、そのココロは「アイスクリーム(のフレーバー)にキャンディやチョコを混ぜ込む(Mix-in)」から なのだそうです。ちなみにそのアイス屋はSteve'sだそうです。だからFlavorsなんですね。
で、そのFlavorsシステムには多重継承はあってもMix-inという機能はありませんでした。 つまり、当時Mix-inとは多重継承の使い方だったわけです。ですから、そこから考えると(1)は必然です。 そういう流儀がある、というよりは、歴史的に見ると「Mix-inだけを目的としたエンティティ(moduleやtrait)」という考え方そのものが亜流なんでしょうね。 私はこの「Mix-inだけを目的としたエンティティ」をRuby以前に見たことはないので、 「実はオリジナルかも」とひとり悦に入っているのですが、実際に調べてみると先行者はいそうですね。
次に(2)についてですが、先程も述べた通り、元々Mix-inは単なる多重継承の使い方に過ぎず、 仕様の継承や実装の継承に限定されていませんでした。というか、Flavorsにはそんな区別はありませんでしたし。 ですから、仕様の継承を行うinterfaceのことをMix-inと呼ぶのは決して間違っていないわけです。 ただし、
These mix-in or capability classes serve much the same role as interfaces do in C#.
とまで断言すると、「実装の継承はどうした」と突っ込みたくなりますが。
ひさしぶり。灌油をしようと思ったら油が切れていた。10人の乙女のうち、駄目な方の5人のようだ。 結局、油を借りてしのいだのだが、「備えよ常に」という言葉を思い出してしまった。
Mix-inについてコメントをいただきました。まず、shudoさんから。
「"Mix-in"は、当初は多重継承の使い方を指す言葉だった」
僕はRubyでMix-inを知ったもので、大変ためになりました。
正確には「当初は」ではなく、現在でも、です。 多分、海外ではほとんどの人はMix-inを多重継承の使い方として理解していると思います。 私はMix-inの啓蒙の意図を込めてRubyのmoduleを設計したのですが、 首藤さんのような人までが「Mix-inといえばアレ」と認識するようになるとは、クスリが効き過ぎたかな。
次にtmaedaさんから。
Metrowerks の CodeWarrior に PowerPlant という C++ のフレームワークが ついていて、PowerPlant では Mix-in が非常に効果的に使われています。
Ruby と比べてどっちが先か、というのはちょっとわかりませんけれども、 PowerPlant も結構昔から存在していたので、もしかしたら PowerPlant の方 が先かもしれません。
Googleで調べると、PowerPlantは1994年からだそうですから、Ruby(1993年)の方が若干古いですね。 いや、1994年は発売された年だから、開発開始はもっと古いのかな。 いずれにせよ、PowerPlantのMix-inは(C++ですから当然)多重継承の使い方としてのMix-inでしょう。 このようなMix-inの起源は上にも書いたようにMITのFlavorsで1979年のことだそうです。 「Rubyがオリジナルかも」と思っているのは「Mix-inだけを目的としたエンティティ」ですから、 直接は関係ないですね。
それから、suminさんから。
エンティティとしての Mix-in に関しては、Strongtalk ('93) の Mix-in ('94-)は Ruby と同じくエンティティみたいです。もっとも Java がらみで Strongtalk の公開は 2002 年までずれ込みましたから、Matz さんの自負を何ら揺るがすものではないでしょう。Strongtalk は Self の人たちとの共同研究成果なので、Ruby と Mix-in 発想の経緯は似たものだったように推察しますが、(Ruby の Mix-in に関しては Self ゆずりということで)当たっていますか？
StrongTalkは2001年にOOPSLAで発表していたのを聞きました。 その時は型についての話ばかりでしたので、Mix-inがあるとは気付きませんでした。 93年ということはこれもRubyとほぼ同時期ですね。
プロトタイプベースのSelfにはクラスがありませんから、Mix-inもないんじゃないかと思います(StrongTalkにはクラスがあります)。ですから、RubyのMix-inがSelfゆずりということもありえません。
私のMix-inについての知識は以下から来ています。
『CommonLispオブジェクトシステム - CLOSとその周辺 -』, Bit1989年1月号別冊、共立出版
5章「共通例題による他の言語との比較」p.84にExplorerのFlavorsの紹介があり、 その中でMix-inについて説明しています。 ほんのわずかの記述ですが、私のSteve'sについてなどの知識はここからです。 書いたのは日本ユニシスの川辺さん。
SuperASCII 1992年6月号
Browsing OOPLという連載の2回目。 「OOPLの最新モデルとしてのLisp」というタイトルでCLOSを紹介していますが、 この中でMix-inの紹介をしています(p.121)。これを読んで初めてMix-inについて理解できました。 書いたのは日本電気の佐治さん。
で、これらの知識をベースにMix-inを啓蒙(強制)するために考えた仕組みが、 「Mix-inだけを目的としたエンティティ」であるRubyのmoduleです。 ですから、発想としては独自ですね。1993年のことです。