プロトタイプベース・オブジェクト指向

1 名前：デフォルトの名無しさん [03/12/08 21:30] オブジェクトを複製または継承によって生成を行う言語， プロトタイプベース・オブジェクト指向言語について語りましょうよ． 関連リンク >>2 652 名前：デフォルトの名無しさん mailto:sage [04/12/22 02:19:44] >>651 委譲を使うコードがむちゃくちゃシンプルになる。 ttp://homepage.mac.com/mkino2/oop/chainOfResp/ 653 名前：デフォルトの名無しさん mailto:sage [04/12/22 04:15:44] >>650 > Smalltalk流にパーシスタント・オブジェクトの集合してシステムが出来上がってるものの場合、 > クラス（←これもまた何かのインスタンス）を動的に変更できない方が不自然な感じがする。 それで実際、クラスどころかオブジェクトのサイズから属性やメソッドまで動的に 変更できるわけです。 654 名前：デフォルトの名無しさん mailto:sage [04/12/22 05:59:54] プロトタイプベース言語のミニマルセットの定義ってどこかに無いですか？ できれば書籍が一番うれしいのですが。 googleじゃ引っかからなかった（英語圏は試してない） 655 名前：デフォルトの名無しさん mailto:sage [04/12/22 11:28:30] >>654 ミニマルではないけれど、インスタンスベースを語る前に、少なくとも これだけには目を通しておくべきかと思います。 ttp://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html インスタンスベースの考察については、英語でちょっと高い本ですが A Theory of Objects (ISBN: 0387947752) ttp://www.amazon.com/exec/obidos/tg/detail/-/0387947752 がそれなりにページを割いていて、比較的詳しいです。これを読むと クラスベースとプロトタイプベースに本質的な違いはなにもないことも 分かります。 656 名前：デフォルトの名無しさん mailto:sage [04/12/22 12:49:57] SELF に関しては、メッセージ送信重視の立場と、インスタンスベースの 立場を分けて評価する必要があります。たとえば、インスタンス変数を 持たず、スロットを振る舞いと属性で共有することについては、名前の 衝突の問題が生じることがすでに分かっています。（つまり、スロット アクセスを多態させるときに getXXX などと別名を設けないといけない） こうした問題はメッセージ送信重視の立場から来るもので、インスタンス ベースであることとは関係ありません。 SELF はメッセージ指向寄りの（しかしメッセージ指向とは違う、単に メッセージ送信重視の）立場から、Smalltalk の実装に対して生じた 疑問、あるいは想定しうる理想像を具現化して見せたものとみることが できます。その結果生じたもののひとつがインスタンスベースだと 考えておくのが無難です。つまり、インスタンスベースの特徴は SELF に見ることができますが、SELF の特徴すべてがインスタンスベースに 当てはまるわけではないということです。 インスタンスベースの他に、SELF の副産物としては、コスト高で最適化 が難しいメッセージ送信の行きすぎた(笑)徹底により、VM の高速化技術 が生まれたことが挙げられます。これは Strongtalk という静的型チェック 機構を持つ Smalltalk の派生物を経て、現在、Java VM に役立てられて います。 657 名前：デフォルトの名無しさん mailto:sage [04/12/22 14:06:15] >>656 > getXXX などと別名を設けないといけない スミマセン。これ嘘です。getter ではなく setter のしかも、SELF では なく Io の言語仕様上の問題を思い違いしておりました。忘れてください。 658 名前：Aransk [04/12/22 19:01:04] 例えばこんなパースペクティブもありかなと 考えていること： 言語論的に申し上げればフィンランド語は動詞の変化 だけでも30型あります。ヨーロッパ系言語のなかでは 最も複雑な文法体系を有しております。 ご承知の通りフィンランドの教育水準の高さは世界の 他の国を圧倒しております。つまり使いこなせれば 言語は精緻であればあるほど頭脳を進化させます。 コミュニケーションの幅が広がる次第です。 西サモア諸島の言語は現在形しかありません。 プログラミング言語と同じです。 従ってプログラマーの頭脳水準は…。 なんてことを言いたい訳ではありません。 つまり精密なルールは文明の進化に負っております。 で、話をインスタンスにメソッドやフィールドを 持たせることに戻ります。 クラス概念の精緻化というパースペクティブから解釈 するとそれは単にルールを破っていることに過ぎない。 また、LispやSchemeの言語文法自体を変化させる マクロは言語自体を破壊することになる。 これは不自由で精緻なルールがあるから 人間の頭脳は進化するというパースペクティブから の意見です。 659 名前：デフォルトの名無しさん mailto:sage [04/12/22 19:32:17] >>656 Programming as an Experience: The Inspiration for Self にも出てくるけれど、 「スロットで振る舞いと属性を共有する」 つまり 「スロットの中身が値ならそれを返して、 メソッドオブジェクトならそれを実行する」 というやりかただと、 メソッドオブジェクトを値としてほしい場合に困るっていう問題があります。 これに対してSelfではmirrorオブジェクトというのを使うみたいです。 660 名前：デフォルトの名無しさん mailto:sage [04/12/22 22:24:18] >>655 おお。SELFってこういう物だったんだ。参考になるなあ。 661 名前：デフォルトの名無しさん [04/12/23 03:08:03] >>652 CoRなんてごくたまに使う程度のモンじゃない？ LispのLambda式みたいに、CoRベースの世界が構築できるなら別だけど、 クラスベースOO言語とくに静的型付の普通の言語のメリットには遠く及ばないよね。 662 名前：デフォルトの名無しさん mailto:sage [04/12/23 04:21:44] つまり和訳すると、委譲がすっげーシンプルに書けるのを見て ちょっとびっくりしちゃったわけね…。 663 名前：デフォルトの名無しさん mailto:sage [04/12/23 12:29:21] クラスベースでならメタ・プログラミングが必要な場面で、 現状のクラス・ベースでは、そういった場面をデザインパターンや クラス・システムの拡張で対応しているが、(そのシステム数だけ、それを特徴とした新たな言語を生み出している) プロトタイプでは一般的な概念の枠内で拡張し対応できる。 例として、AOP拡張とかプロトタイプ・ベースの言語で提示してみるのはどうでしょう? 例えばJAVAがソース or バイトコード変換といった手段で実現している事を、 プロトタイプ・ベースでどれだけ簡単に出来るかというのを比較してみると面白いかもしれません。 664 名前：デフォルトの名無しさん mailto:sage [04/12/23 12:37:48] >>663 classがfirst class objectであるかどうかの問題とゴッチャになってないかい？ 665 名前：デフォルトの名無しさん mailto:sage [04/12/23 12:47:50] 漏れはそういったハードコアな分野ではクラスベースとの差異はあまり無いと思ってる。憶測だけど。 とはいえAOP関連だと、特定のインスタンスのみにコード挿入するとか、クラスベースでは出来ない ものも簡単にできるのも確か。 でも、さんざ既出のDHTMLのようなものが簡単に書けるというのがプロトタイプ言語の特徴だと思う。 クラスを沢山作らなくても、複数のimgタグでonClickの動作を変えられるし。.NetのSystem.Windows. Forms以下の各種コントロールにイベントハンドラを記述するというアーキテクチャなんかも、これは prototype言語の守備範囲なんじゃないか？とか思うし。 666 名前：Aransk [04/12/23 15:45:54] C < Pascal >C++ < Java >CommonLisp < Scheme >Smalltalk < Self >と思うわけですよ．この気持わかるでしょ？ その気持ちはすっごく分かる。 幼稚園時代だけど。W 不思議と実用性は前者が高いんですよね？ C++とJavaのケースを除き…というか 本来の意味の実用性で言えば個人的には C++とは思いますが。 理由として考えられるのは アカデミックな理論整合性より現実の ソリューションは複雑であるということが 一つ。 もう一つはプログラマーの専門性の問題です。 誰でもとっつき易いものでは食えない が、しかし、あまりに少数しか分からないもの でも職業として成立しない。 このパースペクティブから、プロトタイプ言語の 自由度は協業度の面でマイナスとして 作用しないのでしょうか。 つまり作った奴しか分からないというか 作った本人もどのインスタンスに細工したのか 忘れてしまうとか。 667 名前：デフォルトの名無しさん [04/12/23 23:31:59] >>664 ごっちゃ通貨、それは包含関係にあるのでは？ 何か問題が？ 668 名前：デフォルトの名無しさん mailto:sage [04/12/24 01:54:13] >>667 クラスをfirst class objectとしているクラスベース言語が多数ある以上、 >>663は完全にトンチンカンなわけだが。 669 名前：663 mailto:sage [04/12/24 08:40:35] AOPって例がまずかったかな? first class objectって時点で、 多くのプロトタイプ(インスタンス)ベースの実装と本質的には同じものになるだろうけど。 クラスやオブジェクトの拡張がクラス・ベースの概念の枠内でどのように扱われているかという点において、 クラス・ベースの言語ではメタ・プログラミングが必要な場面で、 プロトタイプ(インスタンス)・ベースでは自然に備わっている特徴で解決出来る。といった主張でした。 670 名前：Aransk [04/12/24 10:41:39] 常に物事は批判的に検証するなかでしか 重みや深みは付加されません。 敢えてプロトタイプベースの命綱でなる オブジェクトに対するメッセージパスについて 伺いたい。 本質的な機能として引数を指定して関数を 呼び出すこととの差異はなんでしょうか？ つまり敢えて擬人化した名前を付することに よる効果の方が実質を上回っていないの でしょうか。 671 名前：デフォルトの名無しさん mailto:sage [04/12/24 13:16:06] >>669 >クラス・ベースの言語ではメタ・プログラミングが必要な場面で、 >プロトタイプ(インスタンス)・ベースでは自然に備わっている特徴で解決出来る。といった主張でした。 例示してください。 672 名前：Aransk [04/12/24 18:07:28] >sumim.no-ip.com:8080/wiki/493 リンクを外しておられませんでしょうか？ 673 名前：1 mailto:sage [04/12/25 21:11:44] >>Aransk >インスタンスは持てちゃ駄目なんです。 なんで？ 駄目な理由を述べよ。 >誰でもとっつき易いものでは食えない これ、クラスベースに対するプロトタイプベースのルールの少なさに対して言ってるんだよね。 バッドノウハウでしか食ってけないプログラマなんていらないよ。 このスレもいつの間にか1年経ちましたねぇ。 674 名前：Aransk [04/12/26 17:30:24] １．ご承知の通りクラスとインスタンス概念の導入は 型生成と実動プログラムを分離したところにある訳です。 従ってインスタンスが自ら変形して新たなインスタンスを 生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような 倒錯した状況を生み出すことになるのです。 ２．従ってプロトタイプベース言語は愛玩用のToyProgramを 作成することにその長所を発揮すべきではないでしょうか。 成熟社会はますます個人の自由な暇潰しを求めます。 そのニーズにぴったり合致した言語ではないでしょうか。 と、まぁ敢えて批判的に申せばこうなります。 ところで１っつぁん、>>670に対する 貴方ご回答を期待しておるのですが？ 675 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:35:31] >>674 クラスベースはオブジェクト指向の誕生と同時に誕生したと思っていたが 考え方が根本的に違う プロトタイプベースの利点は、既存のオブジェクトを（ある程度まで）自由に弄れる事 例えば、HTML で記述された既に画面上に存在するボタンなどに追加の挙動を割り当てられる等 クラスベースだと、予め全てのボタンを定義しておかなければいけないという制約が付く オブジェクトを変更させない方に特化するか、変更させる事に特化させるか どちらも同様にニーズがあることは自明で、どちらが優れているかは議論すべきじゃない と俺は思う ……というか、クラスベースとプロトタイプベースのどちらが優れているかなんて 日本語と英語のどちらが優れているかを議論するようなもんだろ？ 676 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:36:00] >>674 というか、>>670 の『擬人化』の意味が良くわからんとですが 677 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:54:22] >>675 日本語の方が優れています。 これは全世界で一致している見解です。 と言ったら？ 678 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:56:17] 現存アプリ数を考えればクラスベースが優れていることが明白なんだが。 679 名前：デフォルトの名無しさん [04/12/26 19:06:29] Ｒｕｂｙ ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ ｐｕｒｏｔｏｔａｉｐｕ 680 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:20:43] >>678 すごいなぁ 幾ら優れている言語が出来ても、初めのうちは糞言語ですか 681 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:25:32] >>678 考えることをしなくなった人間ってのはもうおしまいかと。 682 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:30:31] Ｒｕｂｙ以外は必要ない。 683 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:35:40] >678 それいったら「構造化サイコー」になっちまうが…… いくつのプログラムがCで書かれていると思っているのかね？ PerlやPHPみたいな「ちょっとオブジェクト指向」もたくさんあるし 684 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:49:08] ＞いくつのプログラムがCで書かれていると思っているのかね？ やたらと。それがなにか？ 685 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:49:55] >>683 OOPLとOOを混同しちゃだめだよ。 686 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:52:03] どれだけのスクリプトがRubyでかかれているかしっているかね？ 687 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:53:37] >>686 数えるほどしかないよ 不可能な数じゃない がんばれｗ 688 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:55:22] プロトタイプベースだとウィルスとか簡単に作れるね proto ↓ object を proto ↓ ウィルス ↓ object にするだけで全体感染する 689 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:55:40] >674 >インスタンスが自ら変形して新たなインスタンスを生成することは インスタンスが「勝手に」変わるわけじゃねえって。 プログラマがインスタンスを加工して目的のインスタンスに 近づけているんじゃねえかよ。 >鯛焼きの鯛が金型無しで鯛焼きを作るような はあ、型や設計図が無いとモノを作れないのかな？Aranskは。 プログラマは鯛焼きだけ作れりゃいい、つうわけでもないだろうに 鯛焼きの金型じゃ、お好み焼きは作れんわ >２．従ってプロトタイプベース言語は愛玩用のToyProgramを  あと、 ・アイディアを検証するための「実験プログラム」 ・実際に動かしながらプログラムを作成する「成長プログラム」 なんかも、柔軟性と即効性を考えるとちょうどいいかもねぇ まあ、職人＆日曜大工向けのツールだわな。 コーダーには触らせたく無いねぇ 690 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:56:17] 先輩はルビヲタです。 wでvi *.rbとかやってるとああ、どっかではたらいてんだなと。 691 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:56:52] Ruby!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 692 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:57:01] >688 どうやってプロセスに潜り込むの？ 693 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:05:17] >>692 実際Smalltalkみたいな環境だと簡単にできる 694 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:08:10] >>688 ばーか superclass ↓ ウィルス ↓ subclass にするだけで全体感染しますよ 695 名前：692 mailto:sage [04/12/26 20:10:31] >693 Smalltalkはクラスベースでつな。 クラスベースもプロトタイプベースも関係ないような…… 696 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:18:21] > 従ってインスタンスが自ら変形して新たなインスタンスを > 生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような > 倒錯した状況を生み出すことになるのです。 考え方がクラスに縛られてますね。 クラス・ベースで考えるならこの場合はfactoryパターンを参考にするといいと思います。 プロトタイプベースで言い直すなら、鯛焼きの *インスタンスに当たるもの* はその鯛焼きの複製です。 金型のインスタンスが鯛焼というのはクラスベースの概念で解釈した場合で、 プロトタイプの世界では、タイヤキとその金型はそれぞれ独立したオブジェクトであり、 金型の複製が鯛焼になるという事はありません。 インスタンスという概念自体がclassベースのものである事に注意して下さい。 つまり、誤解の原因はインスタンスだと思っていたそれが、プロトタイプの世界ではインスタンスではなく複製である事。 オブジェクトが存在するためにクラスといった概念を必要としていない為、 インスタンス生成といった作業自体が必要ないのです。 敢えて、このクラスやインスタンスという概念をプロトタイプ・ベースに導入するなら、 金型オブジェクトに鯛焼オブジェクトの複製を生成するようなメソッドを持たせるとわかりやすくなると思います。 この場合でも、金型はクラスといった概念ではなく、金型自身が具象化したオブジェクトであり、 金型にも細工を施し、別の形のたいやきを生成したりする事が出来ます。 クラスを、オブジェクトの定義宣言みたいに考えると、 定義がころころ変わったり、鯛焼がある日突然卵焼になってしまうと困るといった主張は理解できます。 が、これはクラスベースで思考しているからであって、プロトタイプ・ベースでは、 金型が変わったからといって、すでに作られた鯛焼まで変わってしまうとは限らないのです。 ところで、擬人化して語ると、複製を作るといった作業が身近な例に当てはまらないので、 メタファを作るのは難しいかも知れませんね。 コンピュータ上の概念で説明するなら、データのコピーで済ませられるのだけど。 697 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:42:56] 話がプロトタイプの根幹について流れているのを途中で止めてしまうんで荒れちゃうかもしれんが。 プロトタイプベース言語のメッセージパッシング時の最適化に関する論文とか資料へのポインタをご存じの方がいたら示唆お願いしますです。 NewtonScriptもどき作ってるんですけど_Parentの_Parentの………とセレクタ追いかけ回すのめちゃくちゃ重くないですか？ 698 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:47:54] >>697 問題ない。俺が作ったときは proto を追尾しなかったw 最終的に clone 時にスロット全部コピーしたからなぁ まあ、俺も知りたいところではあるが 699 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:58:15] >697 そこはオレも悩んでいるんだけど、やっぱりキャッシュするしか無いかな…… freeze - thawを導入して、protoの変更タイミングを通知するようにするか、 protoが変更されると全てのキャッシュが無効化されるようにするか…… 700 名前：デフォルトの名無しさん mailto:sage [04/12/26 21:09:50] >>697 Selfの論文が山程ある。 701 名前：デフォルトの名無しさん mailto:sage [04/12/27 14:53:52] >>697 ttp://research.sun.com/self/papers/papers.html のImplementationに関する論文でしょう(読んでないので違ってるかもしれない)。 Type inferenceについての論文も関係あるかも。 702 名前：697 mailto:sage [04/12/27 15:58:45] SELFのはSunのサイトに標題一覧があるのですが（701さんサンクス)ACM会員じゃないからなぁ。 大学に聴講生制度あったはずだから登録して図書館で探すしかないのかorz ACMの論文集って普通の図書館でも取り寄せ効きますか？ 703 名前：デフォルトの名無しさん mailto:sage [04/12/27 16:02:10] PSとれるでしょ? 704 名前：Aransk [04/12/27 17:03:03] ttp://sumim.no-ip.com:8080/wiki/493 より引用： >実はプロトタイプベースは、クラスベースと相反するものでは >なく、クラスベースより一段階プリミティブなものだと >考えると、つまり、プロトタイプベースにいろいろな機構 >（トレイトとしてクラス）や制約（独自メソッドの追加や >再定義、インスタンス変数の追加を禁じる）を設けることに >よってできたのがクラスベースだと解釈すれば何ら問題が >ないことが分かりました。 これって卓見だと思う訳ですよ。 優劣の問題ではなく、クラスベースってプロトタイプ ベースより進化した形態なんだと思う。 つまりコピー機能（型生成）と実プログラム機能を分離する ことでより構造化されたプログラミングパラダイムを 生み出した訳です。つまりある自由度、（古くはgoto文）などを 規制することでより間違いの少ない安全度の高いプログラミング レベルを目指してきました。 個人的になんでも出来ることと、協調してプログラミング作業を する場合とは違うということです。 さらに出来ることと出来ないこととは違います。 必ずしも前者が後者をスパーシードしているとは言えないのです。 擬人化とは： 例えばメッセージパッシングってオブジェクトが オブジェクトにメッセージを送っているようなイメージが あります。しかしCの関数呼び出し、やCobolのサブルーチン の呼び出しと実態機能的にそう変化はないのではない でしょうか。 つまり単なる名前だけによるプログラミング機能のラッパー的 要素が含まれているように思えるが…。 705 名前：デフォルトの名無しさん mailto:sage [04/12/27 18:19:40] >>702 大部分の論文はciteseerその他からpdf版も手に入るみたいです。 706 名前：デフォルトの名無しさん mailto:sage [04/12/27 18:38:28] >>704 > さらに出来ることと出来ないこととは違います。 ここが藁い所なのか？ 707 名前：デフォルトの名無しさん mailto:sage [04/12/27 19:16:09] メッセージパッシングっていうのは別にプロトタイプ言語固有の用語ではなくって、 ごく一般的な言葉だと思う。 もちろん本質的ではないし、このスレでも使っているのは１名のみに見える。 あと ＞必ずしも前者が後者をスパーシードしているとは言えないのです これは誰しも同意するだろうけれども、何かを含意していないと無意味な主張。 で含意している内容が「クラスベースってプロトタイプベースより進化した形態なんだと思う」 ならば、「そうですか」としか言い様がない。確かにDHTMLの保守性は悪い。 爬虫類は両生類より進化している、という主張は可能だろうけれども、 サンショウウオ本人やサンショウウオ飼育者にとって、その主張に何か意味があるか、 というとかなり疑問。鳥は恐竜よりも進化している？でも鳥よりも恐竜の方がずっとクールでカッコイイよ。 708 名前：1 mailto:sage [04/12/27 21:15:22] >>Aransk >>670 > 本質的な機能として引数を指定して関数を > 呼び出すこととの差異はなんでしょうか？ > つまり敢えて擬人化した名前を付することに > よる効果の方が実質を上回っていないの > でしょうか。 どうもメッセージ送信と関数呼び出しの違いを 気にしているようですが、それとプロトタイプベースとの関係がわかりません。 メッセージ送信モデルと関数呼び出しモデルの一番重要な違いは 受け手であるプログラマの解釈である私は思います。 中でやってることは同じ場合が多いことはあなたも知っているかと。 あなたの言う「本質的」や「実質」が何を指しているのかがわからないので、 うまく答えられてないですね。すみません。 >>674 > １．ご承知の通りクラスとインスタンス概念の導入は > 型生成と実動プログラムを分離したところにある訳です。 > 従ってインスタンスが自ら変形して新たなインスタンスを > 生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような > 倒錯した状況を生み出すことになるのです。 倒錯した状況ねぇ…それがインスタンスはメソッドを持てちゃ駄目の答えですか。 それはつまり世の中のほとんどのプログラムがクラスベースで書かれているから という答えと変わらないんじゃないですか？ 何故それが「倒錯」と言えるのかを示さない限り。 クラスベース的な鯛焼きのメタファをプロトタイプベースに当てはめてみて こいつはおかしい! と自信たっぷりに言われましてもどう対応していいやら… 709 名前：689 mailto:sage [04/12/28 02:35:50] >優劣の問題ではなく、クラスベースってプロトタイプ  >ベースより進化した形態なんだと思う。  進化<->退化という同一ベクトルにある話じゃないと思うんだけどね 自分だけだろうけど、 プロトタイプベース 　「全てを持つ」要素を組み上げてシステムを構築 　->細胞的、生体組織的 　　柔軟な、増殖的 クラスベース 　全てを記した図面から要素・組織・システムを作り出す 　->機械的、人工物的 　　効率的、最適な といったイメージがあるなあ 710 名前：デフォルトの名無しさん mailto:sage [04/12/28 07:28:23] とりあえずAranskは>>90-206や>>239-276および>>362を読め。 711 名前：デフォルトの名無しさん mailto:sage [04/12/28 11:59:39] >>709 >進化<->退化という同一ベクトルにある話じゃないと思うんだけどね 特殊化と言うんだと思う。 ある差異を「特殊化」というか「進化」というかは、純粋に発言者の観点の違いでしかないのだけれども。 すぐ死んでしまう脊椎動物は原生動物よりも進化していると言えるのか、とか、 ウイルスは（その方向はラディカルだけれども）途轍もなく進化した究極の生命形態じゃないのか、とか。 後段のイメージの方だけれども、Smalltalkはそれなりに柔軟で増殖的だと思う。C++ も。Javaは（ｗ 漏れはたぶんSmalltalkについてはVM全体で一つの「インスタンス」とイメージしてるっぽい。 既存のクラスも勝手にガチャガチャ変えるから。 712 名前：Aransk [04/12/28 14:17:21] >一番重要な違いは受け手であるプログラマの解釈である私は思います。 >> さらに出来ることと出来ないこととは違います。 >ここが藁い所なのか？ プログラマの解釈性に甘えて言葉だけが実体以上に イメージを増大させていないでしょうか？ というのが論点の一つです。 例えばRubyで継承したクラスから上位クラスの Privateメンバーにアクセス「出来ない」ようにする ことは「出来ない」のではないでしょうか。 それが欠点ではなく売りになることがおかしい と考えるのです。 またPerlでThere is not more than one way to do it. という売りがありますが、単に言語仕様の輻輳に過ぎない とも言えます。 プロトタイプベース言語に敢えて批判的な立場で 意見を申し上げておりますが…ってゆうか これまでの２ちゃんねるの発言では全てその スタンスを保つようにしております。 メリットの影にあるデメリットにも 光を当てて総合的、多面的な評価こそ 望ましいと考えるからであります。 713 名前：Aransk [04/12/28 14:18:21] ところで、 >実はプロトタイプベースは、クラスベースと相反するものでは >なく、クラスベースより一段階プリミティブなものだと >考えると、つまり、プロトタイプベースにいろいろな機構 >（トレイトとしてクラス）や制約（独自メソッドの追加や >再定義、インスタンス変数の追加を禁じる）を設けることに >よってできたのがクラスベースだと解釈すれば何ら問題が >ないことが分かりました。 この卓見を書いた人はもうこのスレには 参加してないのでしょうか？ 是非ご意見を頂きたい。 714 名前：697 mailto:sage [04/12/28 14:23:40] >>703,705 はい、落としてきました（ACMにjoinしないと読めないのかと思ってました） で、早速読んでおります。 ありがとうございました。 715 名前：デフォルトの名無しさん mailto:sage [04/12/28 14:52:24] このaranskって馬鹿、ほんとに馬鹿だと思ってたら、関数型言語スレ読んで どうしようもない馬鹿だとわかった。 716 名前：John mailto:sage [04/12/28 14:55:36] とりあえず mput.dip.jp/?date=20030912 を読んでプロトタイプベースを理解したつもりになった。 一番重要なのは どのようにポリモーフィズムを実現するか ということにある。 JavaやC++なんかの普通のOOというのは 木構造型に派生していく継承と、それらをまとめるインターフェースによって作られる。 一方で、プロトタイプベースというのはスロットというパーツの 組み合わせて作る。 ここで一番の違いはアクセス保護された変数の扱いにある。 継承の概念があるOOはprotectedというアクセス保護が有効になる。 一方で、プロトタイプベースでは プロトタイプ間の共通変数を作れないデメリットがある。 しかし、プロトタイプ間は独立となっているため、切り離しが可能となる。 つまり、好きなプロトタイプを組み合わせることができるというメリットがある。 717 名前：John mailto:sage [04/12/28 15:02:14] 言葉を変えると クラスというのは メソッドと変数がクラスの中で閉じていることを意味する。 オブジェクト指向では継承という概念で拡張し、 インターフェースという概念でグルーピングする。 一方、プロトタイプ指向でも クラスはメソッドと変数で閉じている。 それらを足し合わせることで、新しいクラスを作ることができる。 この言い回しから思いつくのは プロトタイプベースでは型によるエラーチェックができないことにある。 つまり、実行してみるまで、ポリモーフィズムできるかどうかがわからない。 一方、オブジェクト指向言語では、実行前に型のチェックをするために コンパイル時にエラーチェックができる。 718 名前：デフォルトの名無しさん mailto:sage [04/12/28 15:05:57] >>716-717 クラスベースにおけるクラスとインスタンスの区別が無くなった物がプロトタイプベースだと考えるとわかりやすいよ クラスの継承もインスタンスの生成も、プロトタイプベースにおけるクローンで纏められている コンパイル時にクラスが既に決定しているクラスベースでは、クラス≒型に見立てて型チェックできるけど、 プロトタイプベースでは実行中にインスタンスが生成されるため、機構が単純だが型チェックできない 719 名前：John [04/12/28 15:06:45] 個人的には コンパイル時の型によるエラーチェックは非常に強力だと思うことと、 親クラスを切り替えたいケースはまれであること （特に動的に切り替えたいケースはまれだ） から、プロトタイプより、オブジェクト指向をお勧めする。 720 名前：John [04/12/28 15:11:24] >>718 >クラスベースにおけるクラスとインスタンスの区別が無くなった物がプロトタイプベースだと考えるとわかりやすいよ これはおかしいと思うよ。 結局のところ、インスタンスの定義をしなくちゃいけないわけで、 その定義の仕方が違うだけ。 クラスの継承とインターフェースで定義するのが、オブジェクト指向 （インターフェースは純粋仮想クラス？だからクラスの一種か） クラスの足し合わせでインスタンスを定義するのがプロトタイプベース 721 名前：John [04/12/28 15:12:03] >これはおかしいと思うよ。 おかしいっていうのは、それじゃ理解できないって意味ね。 間違ってるって意味じゃないです。 722 名前：デフォルトの名無しさん mailto:sage [04/12/28 15:25:07] 藻まいら仕事汁。 723 名前：デフォルトの名無しさん mailto:sage [04/12/28 15:30:56] なんかSmalltalkもSelf(の類)も使ったこと無い人たちが大量に香ばしい妄想を・・・ 724 名前：John [04/12/28 15:44:43] >>723 SmallTalkは確かに（ｒｙ だから使われな（ｒｙ 725 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:09:12] >>716 全然違う このスレの前のほう読め 726 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:10:04] >>718 それは静的型付けと動的型付けの違い 727 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:10:59] >>720 > （インターフェースは純粋仮想クラス？だからクラスの一種か） 全然違う。 728 名前：デフォルトの名無しさん [04/12/28 16:26:59] 違うという時は正解を書こうね。 説得力ないよｗ 729 名前：デフォルトの名無しさん [04/12/28 16:31:00] プロトタイプベースが動的型付けじゃなかったら なんのうまみも無いので、プロトタイプベースは動的型付けでいいと思う。 逆に、オブジェクト指向は型を厳密に決めることができるので、 そのメリットは活かさないに越したことは無い。 と思うんだけど。 誰かメリットデメリットをまとめてくれ。 参考程度にどぞー www.atmarkit.co.jp/fjava/rensai3/devworks05/devworks05_2.html 730 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:40:17] >>728 正解は、インターフェイスはクラスではない。これで満足か？ 731 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:48:44] 説得力が必要だと思った時には 結論だけではなくて、その理由を書こうね。 732 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:10:35] 用語も事実認定も滅茶苦茶な奴が電波飛ばしてるな。 正答を知りたきゃ金払えと。 733 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:13:36] 動的な言語の常として これ以上変更する必要がないということがわかってても それを固定化できないってのは辛いよね 例えばあるメソッドを持つ親が必須のオブジェクトなのに 「無い場合」という本質的に無意味な分岐を作る必要が出てくる メソッドを呼ぶときはそれを毎回チェックしないといけない 静的クラス指向やインタフェースを持つ言語なら そのメソッドないとそもそも実行すらできない、 って風に別の保障を付けられる 静的なプロトタイプベースは作れないかね 734 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:22:47] せめて静的なインターフェースを作れる様にして、 それに合致しないオブジェクトをそのインタフェースを持つオブジェクトの プロトタイプには選択できないようにするとか。 まあこの手段でもプロトタイプ設定時「選択できなかった場合」という 分岐は存在してしまうけど、 毎回メソッドごとに不安要素を抱えるよりは健全であると思う インターフェース内での最適化も出来ると思うし 735 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:28:05] 軟体動物に外骨格をかぶせるとか、そんな感じで インターフェースを仮初の型とみなして、 そのぶんの動的なメソッドディスパッチを全て省略できるとか プロトタイプベースの正攻法の最適化って、やっぱ消極的なキャッシュぐらいだろうし 静的な型やインターフェースを持ち込むことでかなり強力になるとおもうんだよね 736 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:35:55] じゃあ作れよ。終了。 737 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:39:31] ↑そんなレスしかしないなら書き込まないほうがマシだとか ちょっとは考えないのかな 考えないんだろうね まそういう人間はそうやって思いつきだけで行動して そのうち人殺しまでやった後気付くんだよな 「愚かだった」って 738 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:53:12] 自分のことはよくわかっているらしい 739 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:55:34] ま、736の愚か者具合は置いといて プロトタイプベースがいつまでも軟体動物である必要はない。 甲冑でも着て体当たりもできるような頑丈な体を望むオブジェクトも必要だろうし メソッドがないだけて終了する恐れのあるプログラムをジャンボ機や管制塔に 納品するわけにいかない オブジェクトの状態を定数化できれば似たようなことができそうだがね 740 名前：デフォルトの名無しさん [04/12/28 18:22:10] Common Lisp はどっち？ 741 名前：デフォルトの名無しさん mailto:sage [04/12/28 18:25:11] >>731 理由ねえ・・・sunのサイトからJava Language Definitionでもダウソして読め。 742 名前：デフォルトの名無しさん mailto:sage [04/12/28 18:27:36] そもそもJavaだって動的型チェックしてるってのに二元論的ステレオタイプは思考停止の元ですな。 743 名前：デフォルトの名無しさん mailto:sage [04/12/28 20:54:23] 動的型、静的型とかいうと正直混乱しますな 動的型＝データに割り当てられた型 静的型＝変数に割り当てられた型 でおｋ？ 744 名前：デフォルトの名無しさん [04/12/28 21:08:52] >>743 コンパイル前に型が決まっているか、（静的） 実行してみるまで型がわからないか（動的） という違いでいいと思うよ。 静的なOOはそのオブジェクトの実態がなんだかはわからないけど 基底クラスなりインターフェース（純粋仮想クラス）なりがわかっているから メソッド呼び出しが成功することが保証されてる。 745 名前：デフォルトの名無しさん [04/12/28 21:12:54] プロトタイプベース（以下PTB)もOOPも 基本になってるのは データとそれに関連するメソッドをパッキングしましょうってこと。 そして、その共通部分を抜き出して定義することで、 １．共通部分を1箇所に記述する ２．メソッドディスパッチ（ポリモーフィズム、動的バインド）で処理フローを簡略化する ということだと思うんだけど ここまでは正しいのかな？ 746 名前：デフォルトの名無しさん mailto:sage [04/12/28 21:13:03] 動的型・チェックだったのか 動的・型チェックだと思ってた 747 名前：デフォルトの名無しさん [04/12/28 21:16:55] OOPではクラスの継承を利用してそこら辺を記述する。 PTBではクラスの足し合わせでそこら辺を記述する。 1つ疑問なのは データとメソッドを「１つに」パッキングすることが目的なのに PTBにおけるクラスの足し合わせだと データは分断されたままなのではなかろうか？ getter/setterを用意すればいいんだろうけど、それって 面倒な気もする。 いまいちプロトタイプベースのうまみがわからない。 誰かわかる人解説してくれないか？ 748 名前：718 mailto:sage [04/12/28 21:21:49] >>720 すまぬ、ちょっと文面が正しくなかった ＞クラスベースのクラス継承とインスタンス生成の区別が無くなった物がプロトタイプベース ちなみにこれは Io のドキュメントに書いてあったような希ガス 749 名前：1 mailto:sage [04/12/28 22:09:39] とりあえずクラスベースのみを指してオブジェクト指向とかOOPと呼ぶのはやめて欲しいです。 どちらかと言えばプロトタイプベースの方がオブジェクトを重視していると思いません？ 750 名前：デフォルトの名無しさん mailto:sage [04/12/28 22:11:27] >>749 それは思いませんが上段には賛成ですね 751 名前：デフォルトの名無しさん mailto:sage [04/12/28 22:12:37] >>747 >データは分断されたままなのではなかろうか？ super::memberとかproto->memberすればいいんじゃないの？ アクセス制限してるならともかく、 親見に行くのにgetter/setterなんて用意する必要ないでしょ 名前探索の方法は言語ごとに異なる要素だから一概にはいえないけど そういやprivateとかpublicとか属性はあるのかね 752 名前：デフォルトの名無しさん mailto:sage [04/12/28 22:18:18] しかし、親がすげ変わる可能性あるって、なんかまともじゃない感じだけど。 どうせ実装上の副産物みたいなものでプロトタイプベースの本質じゃない気がするし、 はやいとこそんな機能切ったほうがいいんじゃないのかね。 protoがhogeだったのに いきなり proto := hage されていいことなんか何もなさそうだよ？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef