検索フォーム

家族的類似プログラミングパラダイム全体に公開
2008年02月24日12:28
（以下、もし既存のアイデアをスキップしていたら、無知を指摘してください）

オブジェクト指向のハイアラーキーは、あるメンバーがそのクラスの特殊性として定義されていなかったら、ひとつづつ上流の特殊性を検索して、ルートの普遍的なクラスまでいたる、という動作をする。

しかし、たとえばクラスＡがクラスＢの差異として定義されていて、クラスＢがクラスＣの、クラスＣがクラスＤの差異として定義されている場合、Ａのクラスに定義されていないメソッドはＢから検索するが、Ｃからは検索しない、というやりかたはどうだろう。

つまり、ＡＢＣＤはどれも似てはいるけれど、ＡとＤをくくる概念はないようなゆるやかなカテゴリーモデルに対応する。いわば、家族的類似によるプログラミングパラダイム。

コメント

びすけっと2008年02月24日 13:25
継承の検索を１階層までしか遡らないということですよね．実装自体はCLOSをちょっとい
じればすぐに作れると思いますが．ただ，検索しないということはメソッドエラーが出るとい
うことなので，面白い例が思いつきません．何かに役に立つなら誰かがとっくにやってます
よね．

どうして，こんな変なものを思いついたのかの方が重要だと思います．それは，これまでの
研究者の価値観とは異なっているわけですから．
安斎利洋2008年02月24日 14:09
オブジェクト指向のクラス定義は、継承から自由になれないけれど、もし継承範囲が一階層に限られていれば、そのインターフェースのすり合わせだけになるから、動的に組み替えたりできるんじゃないか、というのが実際の役にたち方のイメージです。

と書くと分散オブジェクトみたいに聞こえるけれど、別の言い方をすると論理的なプログラミングから、認知的なプログラミング、ということを考えました。

オブジェクト指向のスタイルにのっとって考えると、厳密な問題の構造が自然に作られるわけですが、家族的類似指向にのっとって考えると、「このコードがとんでもない解釈で使われること」を意識するようになる。隠喩的なプログラミングを導くことができる。
安斎利洋2008年02月24日 22:11
たとえば、こんなことになるんじゃないか。

ビスケットのルールセットをクラスと呼ぶことにします。

クラスＡは、独立したある動作をします。
それにクラスＢを加えると、ルールの検索テーブルの上の方に追加され、カスケード式にオーバーライドされていくとします。
こうやっていろいろなプログラムを作っていくと、いろいろなクラスが樹状に出来ていきます。
ビスケットでオブジェクト指向的なヒエラルキーを作るとすると、まずこういう形になるでしょう。
これだと、Ａの影響はずっと残るし、強固でグローバルな規則と制約の構造を組み上げてしまう。

これを「検索を一層まで」という家族的類似にするとどうなるか。

ＢにＣを加えるとき、Ｂが依拠するＡが忘れられてしまうから、とりあえずＣはＡをコピーします。
そして、Ａの中の不要なルールを消し、残ったルールをモディファイし、その上で必要なルールを加えます。
冗長のようだけれど、Ａに縛られないＡのようなものを作ることになる。
このようにして樹を作ると、同じような機能をもったクラスが、樹のあちこちに局所的にできてくる。新しいクラスを作るとき、カンブリアンのように、どこに投稿しようか、ということになる。

認知的プログラミングは、多くの人が創発を狙って参加するようなプログラミングの風景かもしれません。
smi2008年02月24日 23:18
オブジェクト指向プログラミングの勉強をはじめたときに、クラスという用語からも連想されるように、集合論を下敷きにしているのかなと思ったものです。
通常のクラス継承がD⊃C⊃B⊃Aだとして、

D＝¬C,C=¬B,B=¬DでなおかつA⊂D,A⊂C,A⊂Bなら
A=(D∪C∪B)というプログラミング,（これが分散オブジェクトとか多重継承と呼ばれるもの？）
が可能であるならば、
他にも、集合論的なオブジェクト操作が可能だとか。

（雪山より無事生還とおもったら、都内も春の嵐。）
びすけっと2008年02月24日 23:19
昔，学生だったころ，コボルプログラマーの友達にオブジェクト指向の説明をしたことがある
のですが．20年ぐらい前だから，まだ研究の世界でしかその概念はなくて．

で，前に作ったプログラムの差分だけで作れるということを説明したら，そんなこと普通に
やっている，というんです．前のソースコードを似ている部分をコピーして使うと．
僕が，それだと，大元を修正したときに，その修正が伝わらない，という説明をすると，
どうしてそんな怖いことをするんだ，自分が把握していない範囲で勝手に動作が変わるの
は仕事に使えないじゃないか．

ということで，まったくオブジェクト指向のよさを伝えることができなかったわけです．
と同時に，オブジェクト指向は机上の空論なんじゃないかとも感じました．

一階層までしかたどらなくてよい，というのはちょうどいい具合なのかもしれませんね．
それ以上の階層は，とりあえずコピーしなきゃならない．


あと，こういう議論って，当時は山のようにやられてて，学生一人につき，ひとつ
ずつプログラミング言語を持っている，みたいな状態で．なかには，どうやって実装
すればよいのかもわからないものまであって．楽しかったですね．
新しい考え方はどうやって発明されてゆくのか，という過程を見つつ，自分でも
できるんじゃないかってやっていた．
osamu2008年02月25日 00:14
素朴な疑問なんですが、、

Aから始まってその先に、・・・・E←F←G・・・・というのがあったとして、可能性としては、偶然AとGが全く同じ物になることもあり得るということですよね？

例えば抽象クラスAの下に連なる子孫のどこかに、Px　Py　二つは遠い親戚というのがあったとして、Px、PyはAの子孫であることから自由なので、食い物クラスAの子孫であっても、＜ドーナツ＞も＜浮き輪＞も現れうるという意味ですよね？
安斎利洋2008年02月25日 00:41
>食い物クラスAの子孫であっても、＜ドーナツ＞も＜浮き輪＞も現れうるという意味ですよね？

そうそう、そこが狙い目です。そういうことが起こりうるプログラミングパラダイムが欲しい、と。
概念モデルにおけるファジーです。

ファジー同様、応用可能な範囲は限られるけれど、ぴったり会えばなにより簡潔に書けるはず。
安斎利洋2008年02月25日 00:45
>他にも、集合論的なオブジェクト操作が可能だとか。

クラスの樹構造を破るためにインターフェースが使えるわけですが、すべてインターフェースだけなら自由なグラフ構造で継承ができるんじゃないか、ということです。
安斎利洋2008年02月25日 00:49
>一階層までしかたどらなくてよい，というのはちょうどいい具合なのかもしれませんね．

オブジェクト指向は、結局のところ人間（プログラマ）のための整理方法にすぎないわけですが、人間のためじゃないところに、なにかが生まれてこないと意味ないですよね。そこのところ、ちゃんと説明できないとだめだな。考えてみます。
にしの2008年02月26日 00:34
んーーーと考えてたのですが、
これってカンブリアンですよね？

と書いたら、よく読んだら途中に書いてありました。
にしの2008年02月26日 00:42
今のオブジェクト指向でも、実際に使う人は１段の継承しか使ってない（というか使いこなせていない）と思います。ライブラリをこだわって作る人、よほどライブラリを理解している人、これら以外の普通の人は末端一つだけではないかと。

とすれば、現状でも実用的な意味では、ここのモデルに近い気がします。

２段さかのぼる継承がないとかなり不便になるので、そういう継承の実装そのものが広まるかは未知数ですが、
それとは別に、全体像をカンブリアン的にイメージ化して、ライブラリ世界を提示するようなシステムは、それ自体でものすごく受け入れられると思います。
今はそもそもライブラリツリーが実用的に使えるクラスブラウザって無いです。
安斎利洋2008年02月26日 00:45
カンブリアンは、種の影響をすぐに忘れますが、そういう忘れっぽくて弱い継承ができないか、ということは考えました。

完全な全体を目指すのがオブジェクト指向だとしたら、完全体の単一で強いモードから逃れて、多様になることを指向するパラダイムはないか、と。
安斎利洋2008年02月26日 00:48
>それとは別に、全体像をカンブリアン的にイメージ化して、ライブラリ世界を提示するような
>システムは、それ自体でものすごく受け入れられると思います。

これはいいですね。これなら、継承が一段と決めなくても、継承のスコープをグラフで選ぶようなことができますね。
にしの2008年02月26日 00:56
びすけっとさんの「俺達のライブラリs」モデルとか多様でいいですよね。
is-A, has-A　は分かりやすくスジを付けているけれど強すぎる。というのは、実際、myライブラリを作るのに挫折してきた多くの人が体現しています。
ゆるーい結び付きで、部分は完全で、広くとると矛盾だらけだけど、全体としてはモノになっているようなパラダイムの方が、作る人にも使う人にも優しい気がいたします。
いっそクラス相互やモジュール相互のリンクは名目だけで、ライブラリの内容的・プログラミング的に全く関係ない、という「管理構造」はどうでしょうか。。
再発明ウェルカム。で。
（というよりも、現実には再発明の山ですし。たいていそこにバグだらけだし。）
安斎利洋2008年02月26日 01:15
自分ひとりで作っているクラスライブラリも、だんだんオブジェクト指向のうまみを味わうほど、大きくて強固になっていって、強いんだけど自分の決めた法律に縛られていやになってきます。そういうときに、肉を焼く前にスジを切るように、結合を弱くして食べやすくしたくなることがあります。

プログラミングの作法として、これを回避する手はいくつもあると思うんですが、言語の仕組みの中に、「スジ切り」を入れる手はないでしょうかね。
にしの2008年02月26日 12:03
>言語の仕組みの中に、「スジ切り」を入れる
ここがミソですね。

スジを通すことばかり考えてきた、あるいはそういうのが好きな人が作ってきた、あるいはそういうのが好きな人がプログラミングも好きなので、現状のように固くならざるおえなかったのは当然といえば当然です。
サイズが激しく大きくなったときの考え方は、精緻さと統一にこだわるまじめで「科学的」（多分「工学的」）な人には作り出せない気がします。

構造を持たせずに検索システムやタグなどで再構築するのが流行ってますが、それとも違う気がします。カンブリアン・もしくは連歌的ライブラリアンって期待が膨らんできました。

--
繰り返しですが、現場的にはすでにスジを通してないと思います。
そこを明示的に示してサポートする感じなのかもしれません。
ともかく、部分ＯＫ全体知らん、のシステムが自然・必然なんだと思います。

　安斎利洋mixi日記　一覧へ