[ruby-list:6323] Re: ruby's design policy (Re: I'd like to subscr ibe this ML)

まつもと ゆきひろです

井上さんROMじゃなくなってますね ^^;;;
良いことだ…．

In message "[ruby-list:6322] Re: ruby's design policy (Re: I'd like to subscr ibe this ML)"
    on 98/02/06, INOUE Katsuyuki <[e-mail]> writes:

|スクリプト言語では，型について考えなくてよいという性質は，その言語の特
|長というよりも，必須の条件だと思います。

私もそう思います．

|>     引数がある型に適合しているかどうか保証する必要はなく，た
|>     だあるメッセージに反応するかどうかだけで適合が決まるので，
|>     不自然な継承関係を作る必要はありません．
|
|これは，静的型言語でも，interface を使うことで，(実用上，困らないくら
|い)緩和されるように思っているのですが，認識が甘いでしょうか?

いや，そうだと思いますよ．もっとも動的型システムではまったく
考えないわけですから，「この仕様(のサブセット)は継承階層を跨
るからinterfaceを用意しなくちゃな」などと考える必要さえない
わけです．お手軽という見地からはそういうことさえ考えたくない
わけです．

# いや，考えるのは悪いことじゃないですよ．いつも考えなくちゃ
# いけないのが疲れちゃうだけで．

|>     更に型チェックが動的に行われるため実行コストがかかる場合
|>     もあります．
|
|実行コストをかけずに，動的な型チェックができるのでしょうか。
|よろしければ，教えてください。

できないです(笑)．でも，動的な型チェックって結局メソッドの動
的結合によっているわけですから，これは静的型の言語でもある程
度発生するわけです．あ，でも C++ だと動的な検索はしないな．
# 古い人間であることを露呈してしまった…．

|そもそも，強い型付け + 静的型 + 単一継承 + interface な言語(うーん，
|Java しか知らない)で，モデルを維持したまま，実装を継承するのって，可能
|なんでしょうか?

できると思いますよ．多重継承の代わりにMix-inをすればよいわけ
ですから．fj.comp.oopsで前田さんがJavaにMix-inがあれば良いの
にって発言してましたよね．もしJavaにMix-inを導入したとして，
言語がそのぶん複雑になる以外には別に破綻しないと思います．

|Min-in って，なんでしょうか?
|Mix-in は多重継承と同じ複雑さを引き起こすように，私には感じられるので
|すが，それを抑制するご利益が，Min-in にはあるのですか?

Mix-inは多重継承を行う時に主たる継承元以外のクラスは

  * 通常の継承階層に属さない
  * 具象クラスでない

という制限をつけるというテクニックです．主たる継承関係以外は
is-aの関係ではなく，性質の付加という働きを持ちます．多重継承
における継承関係の複雑化の原因の多くはあるクラスが複数のクラ
スに対してis-a関係を持つことですから，このことによって継承関
係の複雑化をある程度避けることが出来ます．

もっとも，多重継承の問題点のうち，名前の衝突についてはまった
く解決されません．ただ，関係が単純になるだけです．

rubyではMix-inする対象をクラスでなく，スーパークラスをもたず，
インスタンスを作ることが出来ないモジュールに限ることで強制し
ています．

|私も，この辺の解説を ruby 本に期待したいんですが，あんまり詳しく扱っちゃ
|うと，まつもとさんの当初の意図と違う本になっちゃうんですよね?

この部分(なぜ多重継承でなくMix-inか)だけはある程度説明すると
思います．もっとも，今日書いたことの繰り返しになると思います
けどね．
                          いちおうスクリプト言語の本ですから
                                まつもと ゆきひろ /:|)