From: INOUE Katsuyuki <inoue@...>
Date: 1998-02-06T19:10:40+09:00
Subject: [ruby-list:6322] Re: ruby's design policy (Re: I'd like to subscr	 ibe this ML)

井上勝行です。

すいません，適宜編集して引用することをお許しください。

>>>>> Yukihiro Matsumoto <matz@netlab.co.jp> writes:
>   Static Typing(静的型)
(snip)
>     この「元の型に戻す(downcast)」というのは型システムに穴を
>     開ける大変危険な行為です．

C++ でクラスライブラリなんかを組むと，
・多重継承を使って，名前の衝突や共通祖先の問題と闘う
・下向きキャストを使って，型システムをダメにする
・実行時型情報を管理するクラスを用意する
の究極の選択を迫られますよね。
どれをとっても面倒なのに，汎用性や実行効率が落ちちゃう。
で，そうまでして C++ を使いたいのかという疑問が生じる。

>   Dynamic Typing(動的型)

(snip)
>     スクリプト系の手軽なプログラムを作る場合に型について悩ま
>     ずにすいすいプログラムが書けます．

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

(snip)
>     引数がある型に適合しているかどうか保証する必要はなく，た
>     だあるメッセージに反応するかどうかだけで適合が決まるので，
>     不自然な継承関係を作る必要はありません．

これは，静的型言語でも，interface を使うことで，(実用上，困らないくら
い)緩和されるように思っているのですが，認識が甘いでしょうか?

(snip)
>     更に型チェックが動的に行われるため実行コストがかかる場合
>     もあります．

実行コストをかけずに，動的な型チェックができるのでしょうか。
よろしければ，教えてください。

(snip)
> 動的型言語では「仕様の共有」の必要が無いことは既に述べました．
> となると後は実装の共有ことだけを考えれば良いわけですが，ここ
> で単純さあるいは理解しやすさから，単一継承を選ぶとJavaのよう
> に「実装の共有はあきらめる．必要に応じてコピーする」か，Ruby
> のように「Mix-inを採用する」かどちらかになるのではないでしょ
> うか．Rubyはエラーの発生しやすいコピーを避けて(コピーの方を
> 修正し忘れたりするし)，Mix-inを採用したということです．

そもそも，強い型付け + 静的型 + 単一継承 + interface な言語(うーん，
Java しか知らない)で，モデルを維持したまま，実装を継承するのって，可能
なんでしょうか?
継承される実装というのは，特定の interface を use しますね。
つまり，「自分を取り込みたいクラスは，こういう interface を持つこと」
という仕様が決まる。
この場合，この仕様には当然型情報も含まれますから，継承する側としては，
求められる型と互換性がないといけない。
しかし，継承を使って互換性を実現するのは，本末転倒になる。
多重継承が抱える問題を起こさない，新しい方法というのは，私には思い付き
ません。
どうでしょう?

(snip)
> rubyの場合Min-inが強制されていることによって，継承関係が複雑
> になることを言語レベルである程度排除しているといえます．

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

> |で、この辺のことが、ruby 本で解説されていると嬉しいです。

> # 説明しちゃいました．^^;;;
> えーと手元の原稿を見ると1章である程度解説されてますね．まだ
> 書いてない4章にも登場するかも．

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

-- 
井上 勝行 (inoue@pps.sdl.melco.co.jp)
三菱電機 (株) 産業システム研究所 電力・プラントシステム開発部
TEL: 06-497-7144	FAX: 06-497-7290