大村@だんだん話がわかってきました です。
On 2006/02/02, at 2:41, a.nakamura wrote:
> そういう機能をサポートした言語を作ってみたい、とは
> 思ったりもしますが、
> その言語で描ける世界は、JavaやRuby(?)やUMLで
> 表現できる世界を
> 超越しちゃいそうです。
実行時にクラス（型）を動的に生成するという事でしょうかね？
動的に作成される可能性のあるクラスを静的に沢山作っておくよりは
「おもしろそう」な気はします(^^)
> あと、単純に足し引きできるものなのか？って問題も有りますね。
>
> ちょうどJavaのInterfaceを引き合いに出すと話しやす
> いんですが、
> Interfaceだと足し算や引き算は考えることが
> 出来ちゃうかも知れません。
> Interfaceをシグネチャの集合とみなすんです。
>
> というのは、Interfaceの中身って奴は、
> 「同じシグネチャのメソッド」か「違うシグネチャのメソッド」か
> のどちらかしかないからです。
> 衝突してれば単に同一のメソッドだとみなせばいいし、
> 衝突しなければ同一じゃないメソッドだとみなせばいい。
> これなら差も簡単に考えられます。
そうですね。シグネチャの集合であればいつでも演算が可能に
なりますよね。でも、個人的には複数のインターフェースを
実行時に演算して新しいインターフェースを作るっていう
のは上にも書いたとおり、面白そうではあるのですが、
実際の必要性があまり感じられない・・・(^^;。
なにかいい例はあるのでしょうか？
> が、実装(JavaでいえばClass)を含めると…
> (なにを集合に見立てるにせよ)
> 話が途端にややこしくなりそうです。
そうですね。Interfaceはなんてったってシグネチャ
onlyですから。さすがにANDとかXORは無いにしても、
実際の状況でClass AとClass BをORしたり、
ORした後さらに拡張してクラスを作りたい(メソッドの面でも
内部の構造面でも)時ってあるような気がします。
この点は言語側でどうサポートできるのか面白そうなところ
ではあります。
Class A includes B,C,...{...}
なーんてやっちゃいたいw。
もちろん衝突するエントリはどうするか設計できるような
構文が必要ですが。
> 現実(?)的なOOPは、ピュアな集合の世界から
> かけ離れたところを暴走している(^^;、という印象を持ってま
> す。
それはやっぱり、単に物だけを対象にしている集合の世界と
物とそれに付随する属性（機能）の両方を相手にしているOOPの
世界
とのギャップなんでしょうね。
Interfaceはメソッドのシグネチャですから物を機能からとらえた上で
の分類。
物として見た場合は構造上の分類が多いですからこちらは
extendsで。
という風にデザインするとわかりやすくて奇麗だな、思った事が有りま
す。
この「物を機能、構造という二つの面で分類する行為」をちゃんと分離
してやれば
かなりわかりやすくなるように思います。
.__________.. . . .. ._________S_H_I_N_G_O__..
O
M U R A
Shingo Omura
Nagoya Institute of Technology
Dept. of Computer Sience and Engineering
Mail To : *********@*****.***
-------------------------------------
オブジェクトの広場
http://www.ogis-ri.co.jp/otc/hiroba/