- 1 名前：デフォルトの名無しさん [03/12/08 21:30]
- オブジェクトを複製または継承によって生成を行う言語，
プロトタイプベース・オブジェクト指向言語について語りましょうよ．
関連リンク >>2
- 481 名前：デフォルトの名無しさん mailto:sage [04/02/25 19:51]
- >>480
んー Newton Script なんかがまさにそうなんだけど、例えば HTML / XHTML のように
UI + action なんかをさらーっと記述するフレームワークなんかを考えると、ごく当たり前に
プロトタイプベースの発想になったりします。
<a id="a" onClick="hoge()"> a </a>
<a id="b" onClick="bar()"> b </a>
なんていうようなものを表現するとき、それぞれにクラスを作るのではなくインスタンス毎に
メソッドを定義して済ませてしまうとか。
- 482 名前：デフォルトの名無しさん mailto:sage [04/02/25 21:55]
- UI + action というか、
すでにインスタンスベースの枠組み(UI + actionはその典型)があって、
それに乗っかる場合、っていう意味だろうか。
なんか受け身で消極的な感じがする。
- 483 名前：デフォルトの名無しさん mailto:sage [04/02/26 08:19]
- マルチスレッドとの相性ってどうなんでしょうか。
- 484 名前：デフォルトの名無しさん mailto:sage [04/02/26 12:56]
- >>482
乗っかるというか、全体を構築するために使ってもいいし (Newton は後者)。
ただ、フレームワークそのものはクラスベースでいいんじゃない、っていう見解は
ある意味当たり前にあって（フレームワークで定義されるものは普通汎用性を持っていて、
個別インスタンスなんて珍しいから）、そういう面では prototype 言語でも内部的に
クラスを使っていたりします。
↑漏れはNewtonScript と SpiderMonkey (Netscape 由来の JavaScript エンジン)位
しか詳しくないので信頼度低いけど。
- 485 名前：デフォルトの名無しさん mailto:sage [04/03/04 16:33]
- ttp://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/C3_1.html
C++でテンプレートによる「修飾」継承という手で爆発を抑えつつ多重分類を実現できそうな気が。
- 486 名前：デフォルトの名無しさん [04/03/13 12:29]
- あげ
- 487 名前：デフォルトの名無しさん mailto:sage [04/03/19 17:47]
- >>480>>481
保守、ついでに戯言
Delphi の procedure | function 型のプロパティとか、
Java の匿名内部クラスとかでイベントを捕獲するのは、
メソッドをカスタマイズするという点でプロトタイプに通じる考えだと思う。
あると便利、なくてもほかに手段があれば別に困らないかもしれない。
- 488 名前：デフォルトの名無しさん mailto:sage [04/03/20 01:40]
- プロトタイプベース言語の proto ってクラスベース言語の super みたいな物であってますか？
どちらも、元のオブジェクトへの参照を保持しているだけですよね？
- 489 名前：デフォルトの名無しさん mailto:sage [04/03/20 03:51]
- >>488
selfとsuperは同じオブジェクトを指す
- 490 名前：デフォルトの名無しさん mailto:sage [04/03/20 12:52]
- >>489
言語によるかも。
- 491 名前：デフォルトの名無しさん mailto:sage [04/03/20 13:26]
- >>488
SELF のリファレンスマニュアルのこれ、
research.sun.com/self/release_4.0/Self-4.0/Tutorial/Language/SyntaxAndSemantics/Resends.html
なんかみてみてもらうとわかると思うけど、それであながち間違いでもなさそう。
SELF の場合、self は self のままで（まぎらわしいなぁ…）、メソッドの呼び出し記述のほう
に resend を冠する。ただ、これはペアレント（aka proto）スロットが一つのときで、複数ある
ときはそれを明示的にするためにペアレントスロット名をもって resend に代える、とある。
まあ、SELF の話をされてもかなわんよ…という人も多いだろうから、なんか他の言語でも
調べてみることにするか。
- 492 名前：デフォルトの名無しさん mailto:sage [04/03/22 19:33]
- プロトタイプチェインについての覚書（ECMAScript, JavaScript）
ttp://members.jcom.home.ne.jp/jintrick/Personal/d20043l.html#d20_1
- 493 名前：デフォルトの名無しさん mailto:sage [04/03/24 22:39]
- インスタンスを実体、クラスを概念とすると、「継承」というものを現実世界で例えた場合に
プロトタイプベースとクラスベースの、どちらがより簡単で判り易い例えができるんでしょうね
クラスベースはクラス，つまり概念の継承なので、クラスに慣れるとクラスの例は
『クーラーボックスの親はただの箱』みたいでも違和感無いですが、
一般人には？？？な話でしょうし。（ちょっと説明すればわかると思いますが）
逆にプロトタイプの例では特定の個人を例に挙げなければ難しいですし。
（実際にプログラム内で操作するのは「個人」ですから、
実際の例を出せばこちらのほうが俺は判り易いと思いますが）
というかインスタンスとクラスの区別が厳密についてないですね俺 orz
クラスが無い分プロトタイプのほうが簡単ですか？
- 494 名前：デフォルトの名無しさん mailto:sage [04/03/24 22:41]
- > クラスを概念
そこがもーダメなような
- 495 名前：493 [04/03/24 22:46]
- そか orz
判ったつもりで判ってなかったんだな
- 496 名前：デフォルトの名無しさん mailto:sage [04/03/24 22:47]
- ごめん下げ忘れた。逝ってきます。
- 497 名前：デフォルトの名無しさん mailto:sage [04/03/25 12:02]
- >>493
んー。やっぱり プロトタイプベース vs クラスベース という構図が
そも間違っていると思う。プロトタイプベースはよりプリミティブな
オブジェクトモデルなんで、クラスベースがよい仕事をする問題領域なら
機能を制限してそうしたフレームワークを組めばいい（ひらたく言えば
クラスベースを使えばいい） プロトタイプベースが活きるのは、
クラスベースが到達できない領域なのよ。その最たるものがインスタンス
に独自のメソッドや属性を持たせるってやつで。
- 498 名前：デフォルトの名無しさん mailto:sage [04/03/25 12:26]
- >>497
それは別にクラスベースでもできるでしょう。
例： python, CLOS, 他のにもあるハズ
嬉しいのは「よりプリミティブである」って事だけなの？
- 499 名前：デフォルトの名無しさん [04/03/25 12:32]
- 結局Ruby最強ってことで
- 500 名前：デフォルトの名無しさん mailto:sage [04/03/29 13:10]
- 乙
- 501 名前：デフォルトの名無しさん mailto:sage [04/03/29 20:36]
- 500 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 14:16
まえにも見たな、この展開… (w
>>498
とりあえず、任意の instance から別の instance 作れるとか。
class と instance を兼用させるようなことができる。
501 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 14:29
>>500
> とりあえず、任意の instance から別の instance 作れるとか。
> class と instance を兼用させるようなことができる。
で、それも、どっちもclass baseでもできるんだよな。
502 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 17:46
501は
完全に「実現可能」のレイヤーを取り違えているんだよ。
そんなこと言ったら、Ｃでもマシン語だって可能だ。
その区別が付かない奴にいくら言っても堂々巡り。
503 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 17:54
>>498
だから、クラスベースの典型例やそこにおける反例として、
プロトタイプベースの素養を持つ CLOS だの Python をひきあいに
だすなっちゅうの。わざとか？
- 502 名前：デフォルトの名無しさん mailto:sage [04/03/29 20:41]
- 504 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 18:00
>>501
>で、それも、どっちもclass baseでもできるんだよな。
class baseだとclass定義したりそのclassの知識がないとできないから、
ただ「できる」っていうのは無意味。
C言語でOOできると言い張るのと同じ。
prototype baseはinstance を見るだけで追加できるという点で
大きく違う。
それが有効かどうかはともかく。
505 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 18:07
>>498
世に”簡潔は力なり”っていうからねｗ。
オブジェクトが扱える範囲でよりプリミティブであることは
いいことなんでないの？ようわからんけど。
506 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 18:18
>>504
> C言語でOOできると言い張る
それはprototype basedでclass basedもできると言うのと違わない
のかえ?それが許されるなら、class basedでprototype basedもできる
ってのも通るような…
507 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 19:16
形から入る人が多そうなスレですね
- 503 名前：デフォルトの名無しさん mailto:sage [04/03/29 20:48]
- 508 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 19:28
> オブジェクトが扱える範囲でよりプリミティブであることは
> いいことなんでないの？ようわからんけど。
小さい事は良い事!ってなミニマリストにはそうだろうがねぇ．Scheme なんかは
オブジェクトシステム自体が好きにすれば？ということでもっとプリミティブな
仕様になってるが，ミニマリストはあーゆうのが ｲｲ!! って方向にいっちゃうのかね？
でもさ，たとえば加算だけ用意すりゃ乗算は不要ってわけでもないだろ？プリミティ
ブだから良いって言われてもねぇ．なんか利点をガツーンとたのむわ．>>504 の解説
はわかりやすいなー．あとはそれがどのようにクラスベースよりｲｲのかを聞いてみたい．
509 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 21:43
>>508
でもさ、インスタンス特異的メソッドや属性がクラスベースで実現可能だからって
オブジェクトレベルでそれを実現するモデルを採用したオブジェクトシステムが
用なしってわけもないだろ？ なんだ自分で答えてるじゃん。それだよ、それ。
510 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 22:22
お、また堂々巡り繰り返してるな。
511 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 22:23
>>508
そうさねぇ。
他人の作った生きているオブジェクトを
改良できることかなぁ。
.NETのClient side Validationはその具体例かな。
# ただインスタンスにメソッドを追加して回ってるだけなんだけどね。
- 504 名前：デフォルトの名無しさん mailto:sage [04/03/30 01:19]
- 512 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/25 23:13
そして、言語の動的側面を勘違いした椰子が現れて… まわるぅ〜まわるぅよ(ry
513 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/25 23:46
一見ループに見えるが完全に同じではない．循環を断ち切れる事を願ってるんだYO!!
>>509 の意見とか初耳のような気がするぞ．他人の作った生きているオブジェクトを改良できる？
それはプロトタイプベースの特徴なのか？しかし浅学故，それがどうプロトタイプベー
スと関連するのかわからない．オブジェクトの受け渡しと特異メソッドが必要だがプ
ロトタイプベースとは関係ないんじゃ？と思うんだけど違うのかな．
今のところ
1. 「クラス」がないからシンプル
2. 「クラス」がなくても同等の機能（…なの？）
くらいしか理解してないんだが．どうもプロトタイプならではってウリが見えないわ
け．インスタンスのコピーはクラスベースだと苦労が多いけど，プロトタイプベース
にしたら楽になるのかな？コピーの深さの問題はどうしようもない気がするんだけど．
514 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:05
>>513
循環してるのは一部の人の頭の中だけだと思うよ。それを断ち切りたいなら、
何か言語いじってみれ。
- 505 名前：デフォルトの名無しさん mailto:sage [04/03/30 01:20]
- 515 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:34
>>513
プロトタイプベースでは、それなりの規模のシステムではたいてい、トレイトと呼ばれる
クラスベースのクラスと同じ枠組みを作ってそれを使っています。したがって、クラスが
なくても同等…というのは（解釈のしかたにもよりますが）当たりません。
こうした状況はクラスベースの Ruby が特異メソッドを用意しているのと似ていますね。
違いを際だたせるとすれば、Ruby にあるプロトタイプベースの側面は、特異クラスという
ちょっとトリッキーな方法で実現されているのに対して、SELF などでのトレイトは、言語
自体には手を加えずに実現されてているというところでしょうか。
余談ですが、SELF には Ｒｕｂｙ とまったく同様の目的と機能を持つミックスインすら
Ruby よりはるか以前からエンティティとして実装しています。それも、言語仕様には
まったく手を加えずに、です（もっとも、トレイトとミックスインの違いは、継承があるか
無いかの違いだけなわけですが…）。
何度か出ていますが、プロトタイプベースのメリットは、通常は言語仕様として出来合で
エンドユーザー（つまりプログラマ）が変更不能な部分を開放したかたちで処理系が提供
されている（できる）ことではないでしょうか。511 さんの言う「自分で改良できる」という
ニュアンスにはそんなところも含まれているように感じました。
これは、Smalltalk が処理系全体を Smalltalk 自身で記述し、エンドユーザーが自由に
閲覧、変更、拡張ができるようにしているのと似ていなくもないですね。ただ、SELF の
場合は、Smalltalk では変えられない部分も（たとえば、クラスとインスタンスの関係と
いったプリミティブな部分も） SELF 自体でトレイトフレームワークとして表現されている
ために、エンドユーザーが到達可能…というわけです。
Ruby の例に戻ると、仮に特異メソッドやミックスインの振る舞いに不満を感じても、まつ
もとさんを説得するまで仕様の変更は不可能です。しかし、プロトタイプベースなら自分の
好きに変えてしまえばよいのです。もっとも、これをミニマリズム、動的側面のメリットのとり
違い…と言われてしまえばそれまでですが。
- 506 名前：この先、誰か持ってない？ mailto:sage [04/03/30 01:21]
- 516 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:43
>>508
Scheme が好まれるのはミニマルだからというのもあるけど、一番大きいのは
何かを特別扱いする事が少ないってことだと思うんだよね。言い直せば、言語
仕様による制限が取り除かれているってこと。
クラスは便利だけど同時に制約ともなるから、それを言語の根幹に据えるのは
嫌だなぁ。
517 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:46
>>512
動的じゃなきゃプロトタイプベースは成り立たないとおもわれ。
よって、動的であることの利点はプロトタイプベースの利点の一部に必ず含まれる罠。
518 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:49
このスレが活性化するのって、誰かがガンガってソースコードを晒した時か vs. クラスベース
の時かのどっちかだよな。クラスベースの時は大抵不毛な話題に終始するけど。
519 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:55
>>518
んだんだ。
traitsやmixin以外にどんな機能が実現可能か妄想したりするスレとかには……ならないなｗ
- 507 名前：デフォルトの名無しさん mailto:sage [04/04/02 06:23]
- プロトタイプベースな言語で分散オブジェクト環境を構築するのって
結構大変そうっていうかパフォーマンスが苦しそう。
- 508 名前：デフォルトの名無しさん mailto:sage [04/04/02 12:09]
- >>507
うん・・・でもパフォーマンスを考慮した従来型の ORB や RPC に代わって
SOAP とか出てきてる世の中だからなぁ。
- 509 名前：デフォルトの名無しさん mailto:sage [04/04/03 01:41]
- sage ：04/03/26 01:23
プログラム / プロトタイプベース・オブジェクト指向 - 情報
Lispがプリミティブなλ計算そのものだから何でもできるように、
プロトタイプは、OOについてプリミティブだから何でもできる、でいいの？
モノがほかのモノをプロトタイプとして持つってすごく変なモデルの気がするけど、
λ計算みたいに、数学的な意味を持ったモデルなんでしょうか。
プロトタイプがプリミティブたるOOモデルというのが多分数学的にあって、
クラスベースもその中にすっぽり入ってしまうんだと思います。
そういう、本物のOOの定義モデルが実はあるような気がします。
どの言語の何がOOの起源でObjectとはどうだこうだ、というレベルではなくて、
本物のOO定義モデルが。
制約は普通の手続き言語なんかそのものですよね。
チューリングモデルを制約することで使いやすくしているという意味で。
- 510 名前：デフォルトの名無しさん mailto:sage [04/04/03 02:24]
- >>509
まんどくさいから、その辺からツッコミ直してみる。
> どの言語の何がOOの起源でObjectとはどうだこうだ、というレベルではなくて、
> 本物のOO定義モデルが。
prototype baseなモデルMpとclass baseなモデルMcを定義できたとして、
Mp上に仮想Mcを構築できて、なおかつ、Mc上で仮想Mpを定義できれば
どっちが本物とは言えなくなる罠。
と言うと、オッカムの剃刀と言い出す香具師がいるかもしれんが、
OOの全ての機能をObjectに集中させたのがprototype baseで、
オブジェクトの種類という視点では一番簡便になる。
一方、class baseではオブジェクトの生成とオブジェクトの働きを別々に記述するが
これは各機能をより純粋にモデリングしたということでもある。
> 制約は普通の手続き言語なんかそのものですよね。
> チューリングモデルを制約することで使いやすくしているという意味で。
これについては、そうは思わない。
チューリング機械は現代のプログラミング言語よりも表現上の制約を受けている。
つーか、チューリング機械なんて、ヘッドの左右への動きとヘッド位置にある
シンボルの置き換えでしか表現できないんだから、これ以上制約したら
ほとんど何もできなくなる罠。
- 511 名前：デフォルトの名無しさん mailto:sage [04/04/03 16:59]
- > Mc上で仮想Mpを定義できれば どっちが本物とは言えなくなる罠。
これが出来ないんじゃないのかな、
というのが上のレスと思われ。
> チューリング機械は現代のプログラミング言語よりも表現上の制約を受けている。
これについては、そうは思わない。
チューリング機械は現代のプログラミング言語の表現のどのようなモノも、
（表現が長たらしくなるが）表現できる。逆に、
現代のプログラミング言語はチューリング機械の表現のどのようなモノも、
（言語機能と同レベルで）表現できるとは限らない。
「言語機能と同レベルで」ってのはチューリング機械自体をエミュる層をわざわざ作らずに、ということ。
- 512 名前：デフォルトの名無しさん mailto:sage [04/04/03 17:23]
- >>511
> > Mc上で仮想Mpを定義できれば どっちが本物とは言えなくなる罠。
>
> これが出来ないんじゃないのかな、
> というのが上のレスと思われ。
クラスベース環境上にプロトタイプベース環境を構築した例など腐るほどあるが。
> 現代のプログラミング言語はチューリング機械の表現のどのようなモノも、
> （言語機能と同レベルで）表現できるとは限らない。
現代風のプログラミング言語で実現できない例を挙げてみなよ。
つーか、とりあえず構造化プログラミングの論文でも読んでみれば？
- 513 名前：デフォルトの名無しさん mailto:sage [04/04/03 17:54]
- > クラスベース環境上にプロトタイプベース環境を構築した例など腐るほどあるが。
ああ、まったくそのとおり。ずばりエミュだもんな。ぼけてた。
これについては>>510の通り。
> 現代風のプログラミング言語で実現できない例を挙げてみなよ。
チューリングマシンのコーディングは漏れは出来ないけど、
関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？
- 514 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:03]
- まあ、何が言いてぇかっつうと、
Lispだとプリミティブな計算モデルそのものだから、
任意の言語モデルを作って使えるみたいに、
プロトタイプはプリミティブなOOモデルそのものだから、
任意のOOモデルを作って使えるんじゃないかな、という妄想。
まあ、そのためには記法の問題っつうか、
Lispのマクロ相当がないとそのままは使えないけど。
- 515 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:22]
- プロトタイプ機構？ (ﾟДﾟ)ﾊｧ？そんなの余計なお世話。
こんなお仕着せの機構で成り立ったシステムがプリミティブだなんて
あり得ねぇよ。クラス機構と目糞鼻糞。
- 516 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:25]
- >>513
> 関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？
そんなことはチューリングマシンでもできん罠
- 517 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:40]
- チューリングマシンに関数なんてない、
だから相当するモノを作ることになる。
で、自分で作るんだから、
> 関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？
が出来るように作ればいい。schemeで似た事出来るし、出来るでしょ。
はNG？
- 518 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:47]
- >>515
プログラムコードの再利用機構って意味では、委譲ベースでも継承ベースでも
どっちでも良いな。相互排他的な物でもないし。
どっちも無いと困るけど。
肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
変数のスロットはインスタンスローカルで持てるのに、メソッドのスロットを
インスタンスローカルで持てないのって不便。
- 519 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:49]
- >>518
> 肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
> 変数のスロットはインスタンスローカルで持てるのに、メソッドのスロットを
> インスタンスローカルで持てないのって不便。
それ、Smalltalkでは動的にどうとでもできるって話が出てなかったか？
- 520 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:51]
- >>517
エミュるんだったら、プログラミング言語でもエミュるのアリにしないとな。
- 521 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:59]
- >>520
論理的な問題じゃなくて、実際的な問題。
チューリングマシンは概念がないから概念をエミュってなんぼのモノ。
プログラミング言語は、エミュらなくてもすぐ概念を使えるようにしているモノ。
用途で考えれば、プログラミング言語でもエミュるのは無意味。
エミュって概念壊したらプログラム言語の意味ないじゃん。
- 522 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:02]
- >>519
別クラスを生成して become するって話？
それともブロッククロージャを変数に代入してコールするとかかな。
- 523 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:04]
- > 肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
どういう意味でキモなのかわからん。
委譲ベースとか継承ベースとかと関係が見えない。
とりあえず、リフレクション最強、
と言っておけばいいのか？
- 524 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:15]
- >>523
>> 肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
>どういう意味でキモなのかわからん。
>委譲ベースとか継承ベースとかと関係が見えない。
コードの再利用機構 ーー＞ どうでも良い
メソッドの再定義可能性 ーー＞ こっちが重要
リフレクションは実現方法の一つに過ぎないと思う。
- 525 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:15]
- >>518
いやいや、メソッド呼び出しとは何かの定義次第だから、
どっちもなくていいでしょ。それを定義できればいいんだから。
つまるところ、CLOSを産んだLisp最強ってことで。
- 526 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:18]
- >>524
なる。でもそれは必要なのは、
メソッド再定義可能性、じゃなくて、>>525の呼び出しの定義では？
委譲ベースでの定義 自分を捜して、なければプロトタイプから探す
継承ベースでの定義 自分のクラスを探して、なければクラスの親から捜す。
これ以外にもあり得るでしょ。
- 527 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:24]
- 結局、プリミティブなOOモデルなんて存在しねぇと。
クラスベースもプロトタイプベースも目糞鼻糞。
- 528 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:38]
- >>525-526
なるほど、そうですね。
>それを定義できればいいんだから。
までは考えてませんでした。
>自分を捜して
というのがあれば自分的には嬉しいです。
Scheme みたいに、シンボルに束縛されているのが値か手続きか区別しない（
評価する時に S 式の頭にあれば手続きと看做される）ようなモデルがｲｲですね。
メソッドテーブルはクラスに属し、変数テーブルはインスタンスに属するという
のは実装上の都合ですよね。これは一貫性に欠けると思います。特にメソッドが
ファーストクラスなら、尚更。
- 529 名前：デフォルトの名無しさん mailto:sage [04/04/03 20:04]
- >メソッドテーブルはクラスに属し、変数テーブルはインスタンスに属するという
>のは実装上の都合ですよね。
実装って言うか、それがクラス、なのかな？
うーん、クラスってなんだろ。
欲しいのは、
自分を捜して、なければ自分のクラスを探して、なければクラスの親から捜す、
っていう感じ？
しらんけど、Rubyってこんなんじゃない？
- 530 名前：デフォルトの名無しさん mailto:sage [04/04/03 20:17]
- 消えたログの続きが読みたい・・・。
>>509 は >>506 の続きになるのかな。
- 531 名前：デフォルトの名無しさん mailto:sage [04/04/04 00:57]
- >>529
メソッドに話を限れば、クラスは、オブジェクトにとって
・原則として変更が許されない
・無条件移譲先
ですね。逆に言えば、プロトタイプベースのオブジェクトにこのような
制約を課すことで、オーソドックスなクラスベースのオブジェクトが
できあがるわけです。縛りを緩くすれば、プロトタイプベースの要素を
盛り込むことができます。
- 532 名前：デフォルトの名無しさん mailto:sage [04/04/04 01:22]
- >>531
さらに、自分が委ねられたメソッド起動リクエストについては、無条件委譲先
ではなく、あらかじめ別に用意した移譲先に委譲する…という縛りを設ければ
より完全にクラスベースの振る舞いをさせることができそうです。
たとえば、Smalltalk のクラスは（インスタンス）メソッドを持っていますが、
それらはインスタンスから委譲された場合のみ起動でき、自分で起動する
ことはできません。これは先の無条件委譲のしばりが効いていると考えるとうまく
説明できます。また、インスタンスから委譲されたが自分は持っていない
メソッドについては、ここで述べた「自らがレシーバでないときは、無条件
移譲先に委譲できない」という縛りから、二つある委譲先スロットのうち、
無条件移譲先には委譲できず、もう一方、つまりスーパークラスへ委譲せざるを
得ない、というふうに解釈すればよいわけです。
- 533 名前：デフォルトの名無しさん mailto:sage [04/04/04 01:28]
- >>532
このようなメソッドディパッチの観点から言うと、CLOS はそもそも
メソッドがオブジェクトに属しておらず、クラスベースでもプロトタイプ
ベースでもないので、ちょっと脇によけておいた方がよさそうですね。
- 534 名前：デフォルトの名無しさん mailto:sage [04/04/04 01:39]
- じゃ、クラスベースはどんな制限をつけるとプロタイプベースになるの？
- 535 名前：デフォルトの名無しさん mailto:sage [04/04/04 03:08]
- >>534
クラスのインスタンスが常にひとつであるような制約を課すことで(見かけ上の)
プロトタイプベース・オブジェクトを実現できます。
たとえば、Smalltalk のようにクラス自身もオブジェクトで、かつ、メタクラスの
シングルトンであることが保証されている言語なら(非クラスの)インスタンスを
使わず、クラスを使うことでそのままプロトタイプベースプログラミングが(見かけ上)
可能です。
インスタンスに直接メソッドをもたせるような機構にしなければならないのならば、
制約を課すだけでは駄目で、薄いながらも何かしらレイヤーを書いてやる必要が
あるでしょう。
- 536 名前：デフォルトの名無しさん mailto:sage [04/04/04 05:37]
- >>528
> Scheme みたいに、シンボルに束縛されているのが値か手続きか区別しない（
> 評価する時に S 式の頭にあれば手続きと看做される）ようなモデルがｲｲですね。
スレ違いだが、それはどうだろうね。
変数名とメソッド名への制約が増えるから、俺は嫌いだね。
- 537 名前：デフォルトの名無しさん mailto:sage [04/04/05 16:15]
- えーと、「出来ます」ってだけだと、そりゃある程度強力な言語ならあちてい何でもできるわけで、
インスタンスベースのスロットの定義等について、その機構をサポートする簡易な文法があって、
便利に利用できるってことが重要なんじゃない？
例えば、プロトタイプ言語で
human = [ kind: #human, bark() { print("I'm human");} ];
anAho = [ _proto: human, iq: 100, bark() : { print("My name is aho");} ];
とか２行でかけるものを、何行も文を連ねて書いて「出来ます」ってのはなんか違うっていうか・・・
- 538 名前：デフォルトの名無しさん mailto:sage [04/04/06 02:08]
- >>537
簡単なオブジェクトを簡単に記述できるというのは、
スクリプト言語ならば重要な問題かもしれんが、
環境がベースになっている言語ではあまり本質ではないね。
つまり、スクリプト言語に使うのならメソッドを2,3定義するだけでいいものが多いから
1行や2行で書けるかどうかが問題になるが、もっと環境を使ってライブラリ蓄積
していくことを想定した言語では、そういった1行コードは問題ではない。
あと、Modula-3のopaque typeのように一見煩雑に見えるけど
言語機能としてはそれなりに洗練された結果というものもある。
- 539 名前：デフォルトの名無しさん mailto:sage [04/04/06 06:41]
- >>537
流行ってないんでしようがないのだけれども、こういうのはある意味典型的な
プロトタイプ言語のコードなわけで、なんてのかな、>>535の前半のような発想よりは
むしろ↑の方で出てきたクロージャでインスタンスを実現するものの方が指向が
近しいような気がする、というか。。
>>536
>スレ違いだが、それはどうだろうね。
たぶん殆どのプロトタイプ言語でその区別は行われていないと思います。
好き嫌いはともかく。
- 540 名前：デフォルトの名無しさん mailto:sage [04/04/06 07:23]
- >>537-539
あのー、いつの間にモデルの話からリテラル表現の話に飛んでいったのでしょうか？
あと、当然ながら処理系の設計の話もまた別の話だ罠。
- 541 名前：デフォルトの名無しさん mailto:sage [04/04/07 13:17]
- モデルの話は結論？まで逝ったからいいでしょう。>>537-539は解ってなさそうだけど。
ところで、POOとUMLの関係ってどうなん？
- 542 名前：デフォルトの名無しさん mailto:sage [04/04/07 14:26]
- >>532
> さらに、自分が委ねられたメソッド起動リクエストについては、無条件委譲先
> ではなく、あらかじめ別に用意した移譲先に委譲する…という縛りを設ければ
> より完全にクラスベースの振る舞いをさせることができそうです。
それだと、メタ方向の委譲とスーパー方向の委譲が混ざらないか？
- 543 名前：!532 mailto:sage [04/04/08 01:10]
- >>542
メタ方向ってインスタンス←クラス←メタクラスの関係の事？
スーパー方向はインスタンス←クラス←スーパークラスだよね。
>>532
で、>>532 が言ってるのは、foo.bar() で foo のクラス Foo がメソッド bar() を
持っていない時、クラス Foo は（Foo 自身のクラスである） MetaFoo に問い
合わせずに、別に用意されたクラス SuperFoo に問い合わせに行くようにする。
MetaFoo に行くか SuperFoo に行くかは、自分がレシーバかどうかで判断する。
・自分がレシーバの時は自分のクラスに問い合わせる（自分がクラスならメタクラス
に問い合わせる ーー そんなケースあるのかな？）
・自分がレシーバじゃない時はスーパークラスに問い合わせる
であってます？
自分がレシーバじゃないってどう判断するのかな？
プロトタイプチェーンが分かっていないので、変な事を言っていたら済みません。
- 544 名前：デフォルトの名無しさん mailto:sage [04/04/08 02:20]
- 処理系の実装が複数あって、仕様がある程度きっちり決まっているプロトタイプベース
言語って JavaScript 以外にあります？
- 545 名前：デフォルトの名無しさん mailto:sage [04/04/08 08:33]
- >>543
そういう制御をしようとしたら処理系自体に手を入れないと話にならんでしょ
- 546 名前：デフォルトの名無しさん mailto:sage [04/04/10 05:25]
- Smalltalk の SomeClass allInstances do: [foo_proc] みたいなイメージで、
あるプロトタイプを共有しているオブジェクト全てにメッセージを送信する
機能を持っているプロトタイプベース言語ってありますか？
- 547 名前：デフォルトの名無しさん mailto:sage [04/04/10 22:54]
- >>546
細かいようですが、SomeClass allInstances do: [:inst | inst somethingToDo] ですね。
で、本題は SomeClass allInstances みたいなものがあるか？
ということでよろしいですか？ それなら元祖的存在の SELF にすでに
browse childrenOf: obj
というのがあります。プロトタイプスロットに obj を束縛している
全オブジェクトをリスト(a vector) で返します。
- 548 名前：デフォルトの名無しさん mailto:sage [04/04/11 21:24]
- >>547
どうもありがとうございます。
オブジェクト生成する毎に辞書に登録してるのかしらん。
プロトタイプベースの言語は個々のオブジェクトは野放し状態だと
思ってましたが、ある程度の管理はされているんですね。
- 549 名前：デフォルトの名無しさん mailto:sage [04/04/12 02:43]
- >>548
ん〜、でも、Smalltalk においても #allBehaviorsDo: なんかは本来はオブジェクト全部に
問い合わせたりするのがスジだったりするので（高速化のための端折っていますが）
クラスベース、インスタンスベースに限らず、全オブジェクトがオブジェクトメモリ内にあるか、
さらに、それらにアクセスする手段があるか否かってところで、allなんたらな機能が存在しうる
かどうかが決まってしまうような気もします。
まあ、純粋なオブジェクト指向（そんなものがあればの話ですが…(^_^;)）を論ずるとき、
実装において、高速化や最適化がからむ部分は解釈が難しいですね。たとえば、
消えてしまったログの object-oriented pointer で表現されるオブジェクトには“状態”
はあるかないか…なんて話とかもそのたぐいだと思います。
- 550 名前：デフォルトの名無しさん mailto:sage [04/04/12 03:15]
- >>549
> まあ、純粋なオブジェクト指向（そんなものがあればの話ですが…(^_^;)）を論ずるとき、
> 実装において、高速化や最適化がからむ部分は解釈が難しいですね。たとえば、
> 消えてしまったログの object-oriented pointer で表現されるオブジェクトには“状態”
> はあるかないか…なんて話とかもそのたぐいだと思います。
まったくです。正確には、オブジェクトの定義に「状態」は本質かどうか、ですね。
私としては、参照透明なオブジェクト世界が可能である以上は
「状態」は本質ではないと思うのですがね。
オブジェクトを「状態」と「機能」で定義しようという考え方というのは
ノイマン型計算機モデルをそのまま小さくして「オブジェクト」にしているんじゃないか
と思います。
- 551 名前：デフォルトの名無しさん mailto:sage [04/04/15 00:40]
- 参照透明性とは直接関係ないけど、関数型言語の返り値を使って演算していくスタイルは
結構好き。
オブジェクト指向言語は一時変数を作りまくるというイメージがあります。Smalltalk とか、
文法的には返り値を使うスタイルでも全然問題無さそうなのになぁ。
Lisp と Smalltalk を足して２で割った様な言語が欲しい。Self がそうかと思ったけど、
どうなんでしょう？
- 552 名前：デフォルトの名無しさん mailto:sage [04/04/15 00:45]
- >>551 OCamlは？
- 553 名前：デフォルトの名無しさん mailto:sage [04/04/15 00:53]
- >>552
dynamic binding な言語が好きなもので。すいません。
- 554 名前：551 mailto:sage [04/04/19 04:21]
- Slate ﾊｹｰﾝ！
slate.tunes.org/
以前このメールを見た時は、サイトに繋がらなかったのに。
ttp://www.sra.co.jp/smalltalk/SML/archives/2002-October/005955.html
- 555 名前：デフォルトの名無しさん mailto:sage [04/04/19 12:27]
-
C++ の operator() および、 boost::function などの汎用関数オブジェクトは、
型にとらわれない柔軟な仕組みだと思う。C++ は静的でありながら、工夫次第で
動的拡張も可能なモンスター言語だとおもう。
myObject.Connect( "Proc", MyFunction ); // MyFunction を スロットにセット
( myObject->*"Proc" )( 24 ); // MyFunction 呼び出し
とかも出来る。しないけど。
- 556 名前：デフォルトの名無しさん mailto:sage [04/04/19 18:54]
- 言語は色々勉強した方がいいよ。
- 557 名前：デフォルトの名無しさん mailto:sage [04/04/19 19:15]
- Delphiのカスタムバリアント(ﾎﾞｿ
- 558 名前：デフォルトの名無しさん mailto:sage [04/05/05 10:41]
- Self 4.2.1 がリリースされていますね。
ttp://research.sun.com/self/release_4.2/release.html
- 559 名前：1 mailto:sage [04/05/21 21:31]
- hosyu
- 560 名前：デフォルトの名無しさん [04/06/02 18:37]
- どうした？
おまえら。
- 561 名前：デフォルトの名無しさん mailto:sage [04/06/05 00:19]
- selfってWindowsかLinuxじゃ使えないの？
- 562 名前：デフォルトの名無しさん mailto:sage [04/06/05 22:20]
- >>561
一応、あるにはあるのですが…。古いので動かすのは難かしいかも。
ttp://www.gliebe.de/self/
- 563 名前：デフォルトの名無しさん mailto:sage [04/06/09 18:22]
- 今使うならJavaScript一択でしょ。
- 564 名前：デフォルトの名無しさん [04/07/03 01:38]
- プロトタイプベース晒しage
- 565 名前：デフォルトの名無しさん mailto:sage [04/07/05 03:52]
- >>563
一応IoやSmalltalk（Squeak）でもいいんじゃない？
- 566 名前：デフォルトの名無しさん mailto:sage [04/07/06 14:58]
- あれ、だれもProthonに触れないの？
海外で結構人気らしい。
www.prothon.org/index.html
- 567 名前：デフォルトの名無しさん mailto:sage [04/07/15 11:51]
- >>565
こら! Smalltalkはクラスベースだろ。それをプロトタイプベース
に改造した「始祖」がSelfだ。
- 568 名前：デフォルトの名無しさん mailto:sage [04/07/15 12:23]
- アホが一匹紛れ込んでいるので引き取ってください
C＃って死滅する理由がないよね！ Part4
pc5.2ch.net/test/read.cgi/tech/1042464104/639
- 569 名前：デフォルトの名無しさん mailto:sage [04/07/15 20:31]
- >>567
タイルスクリプティング（だっけ？）の部分じゃないの。
- 570 名前：デフォルトの名無しさん mailto:sage [04/07/16 08:05]
- >>569
それはSmalltalkじゃなくてSqueakな…
いってみれば「Cは統合ヘルプ環境がいい」と同じぐらい変。
- 571 名前：デフォルトの名無しさん mailto:sage [04/07/16 10:47]
- >>570
>>565 に Squeak って書いてあるじゃん。
- 572 名前：デフォルトの名無しさん mailto:sage [04/07/16 11:54]
- うち誰かがSqueakシステムにおける、Squeak eToysとSmalltalk言語の区別が
できていない罠。
eToysはSmalltalk言語で記述されているが、Smalltalk言語とは別物の
言語処理系。プロトタイプベースだし、変数には型があり、if-then-elseの
条件分岐構文もある。
ふつう、Squeakと書けば（Smalltalkが併記された場合はなおさら）「Squeakシステム」を、
Smalltalkと書けば「Smalltalk言語」をイメージさせるから「Smalltalk（Squeak）」と
書いてもSqueak eToysを意図しているとは受け取られにくい…
のであります。
- 573 名前：デフォルトの名無しさん mailto:sage [04/07/16 12:06]
- 俺はむしろ、わざわざ Squeak と併記したのは、Morph とかタイルスクリプティングを
匂わせたかったのかと思ったよ。まぁ、好意的な解釈かもしれんが。
- 574 名前：デフォルトの名無しさん mailto:sage [04/07/16 13:50]
- >>573
むしろ？ わざわざ？
- 575 名前：デフォルトの名無しさん mailto:sage [04/07/17 01:28]
- 子供かよ。
- 576 名前：デフォルトの名無しさん [04/07/19 14:47]
- Hage
- 577 名前：1 mailto:haskellsaikou [04/08/12 00:25]
- クラスベースに比べると、記述量的に見てプロトタイプベースは厳しいですかね。
最近Haskell勉強してるんですけど、
「頻繁に使用する少数の道具」が揃っているところが強みだと感じています。
再帰系の高階関数とかコンビネータとか。
そういう厳選された道具がオブジェクト指向の世界にも存在するのかなぁ。
もしあればそれを探し出して、組み込んだ言語ならクラスベースに匹敵するかも。
Lightweight Language が流行っているように
如何に簡単に多くのことを行えるか、がこれからの言語争いで重要だと思います。
# 言うまでもないけど
- 578 名前：デフォルトの名無しさん mailto:sage [04/08/18 02:59]
- 実際ゲームのスクリプトなんかに向いてるみたい。
diablo2 のjspというBOTはjavascript。
まあまあ使いやすかった。
プロトタイプベースである必要はあんまない気がするが。
- 579 名前：デフォルトの名無しさん mailto:sage [04/08/18 08:11]
- というか、使う人が手を入れることを前提とする場合クラスよりもプロトタイプのほうが扱いやすい。
- 580 名前：デフォルトの名無しさん mailto:sage [04/08/18 15:41]
- HTML に埋め込むタイプの小規模スクリプトだと、プロトタイプの独壇場。
- 581 名前：デフォルトの名無しさん mailto:sage [04/08/18 16:44]
- >>580
ボタンや IMG の挙動を変えるのにいちいち別クラスにしたくないな、確かに。
|
 |
