『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
えー、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年のことです。
先日なにげなく登録したOrkut.comだが、Cnetの記事によると「Orkutは会員を限定しており、招待された人しか入会できない」ので、「先週、同ネットワークへの招待状がeBayのオークションサイトで11ドルで落札されたというできごとがあった」のだそうだ。
今はトラフィックの問題で休止中だが、実は貴重な機会だった？
This work is licensed under a Creative Commons License.
「"Mix-in"は、当初は多重継承の使い方を指す言葉だった」<br>へぇ へぇ へぇ へぇ へぇ へぇ へぇ へぇ ...<br>ありがとうございます。<br>僕はRubyでMix-inを知ったもので、大変ためになりました。
初めまして_o_ Mix-in について。<br>Metrowerks の CodeWarrior に PowerPlant という C++ のフレームワークが<br>ついていて、PowerPlant では Mix-in が非常に効果的に使われています。<br>僕は最近使わなくなったのでうろ覚えですが、Observer パターンを付加する<br>LBroadcaster/LListener クラスとか、GUI 部品にドラッグアンドドロップの<br>機能を付加するクラス(クラス名失念)などが、それ単体では意味をなさず、他<br>のクラスに Mix-in して使うことで初めて意味をなすクラスだったと記憶して<br>います。<br><br>Ruby と比べてどっちが先か、というのはちょっとわかりませんけれども、<br>PowerPlant も結構昔から存在していたので、もしかしたら PowerPlant の方<br>が先かもしれません。
Min-in に関しては確かにそうらしいですね。＞クラスの多重継承と根は一緒 これは(Simula は最初から多重継承だと信じていたので)意外でした。ちなみに Flavors は PARC で Smalltalk を見た MIT の研究者が「自分たち(Lisp)なら同じようなこと(メッセージ送信メタファのオブジェクト指向)をもっとうまくやれる」と言って作ったものだとかいう逸話もあります。いかにも Lisp 屋さんらしい言いようで楽しいですね(逆、つまり Lisp 屋ならこう言いかねない…で作られた話かもしれませんが(^_^;))。エンティティとしての Mix-in に関しては、Strongtalk ('93) の Mix-in ('94-)は Ruby と同じくエンティティみたいです。もっとも Java がらみで Strongtalk の公開は 2002 年までずれ込みましたから、Matz さんの自負を何ら揺るがすものではないでしょう。Strongtalk は Self の人たちとの共同研究成果なので、Ruby と Mix-in 発想の経緯は似たものだったように推察しますが、(Ruby の Mix-in に関しては Self ゆずりということで)当たっていますか？
いつごろからこうなってるのか分かりませんが<br>現在、カテゴリ別閲覧モードに飛ぶと月の部分が1Q,2Q,...<br>という風に変に表示されます、tDiaryの仕様ではないですよね？
すみません、「エンティティ」という意味を勘違いしていました。<br>まつもとさんのリプライを読んで気づきました。失礼致しました。
そうですか、ハズしていましたか。残念。CLOS からヒントを得た Matz さんオリジナルのアイデアだったのですね。個人的には似たような話で、Ruby の特異メソッドが CLOS 由来とどこかで書いておられたのを見て、(CLOS の eql specializer よりむしろ Self のメソッドスロットの振る舞いに似ているのに)なぜ Self ではないのだろう…といぶかしんでおりましたが、その謎も解けました。ありがとうございます。余談ですが、たしかに Self にはクラスこそありませんが、フレームワークとして traits (くだんの Traits とまぎらわしいですが…)と呼ばれるクラスと同種の機能を持つオブジェクトがかなり早い時期(すくなくとも '91)から用意されていて、この延長で Mix-in (mixin と呼称) もあります(と言っても、traits との違いは継承ツリーに含まれるか否かだけですが)。Self の mixin の明確な実装時期は分かりませんが、早ければ traits と一緒、遅くとも '94 には Self システムに組み込まれていたようです。Strongtalk の Mix-in もこの流れだと思われます。
「仕様の継承」「実装の継承」についてよく理解していない自分に気づいて，Googleしてみました。見つけたのはこんなところ。<br>http://cvs.cacanet.org/fsc/ruby/ruby1st.html<br>http://web.sfc.keio.ac.jp/~hattori/prog-theory/main_c8_s2.html#doc1_1726<br>そういえば，むかし新人にRubyを教えて，そのあとJavaを教えたとき「なんでInterfaceにメソッドを直接書けないんですか？」ってきかれたなあ。