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

1 名前：デフォルトの名無しさん [03/12/08 21:30] オブジェクトを複製または継承によって生成を行う言語， プロトタイプベース・オブジェクト指向言語について語りましょうよ． 関連リンク >>2 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 されていいことなんか何もなさそうだよ？ 753 名前：デフォルトの名無しさん mailto:sage [04/12/28 22:22:52] >>752 柔軟性を保つとトリッキーなことが出来るとは思うけど、 プロトタイプの本質≠プロトが改変可能かどうか だと思う 親の挿げ替えは、正直あまり使わないな 754 名前：デフォルトの名無しさん mailto:sage [04/12/28 23:42:21] javascriptは親の挿げ替え出来ないよ 755 名前：デフォルトの名無しさん mailto:sage [04/12/28 23:44:46] とりあえず、プロトタイプチェインの挙動には幾つかの種類があると 親の挿げ替えができる／できない 親の変更が子に反映される／されない 756 名前：デフォルトの名無しさん mailto:sage [04/12/29 00:12:05] 要するにクラスベースだとかプロトタイプベースだとか言ったところで継承を実現するためのデータ構造が少々ちがうっつー程度のことだ、って認識でOK? 757 名前：デフォルトの名無しさん mailto:sage [04/12/29 00:13:00] じゃあ一番メジャーなjavascriptを基準にして話しようよ 他の変態プロトタイプベース言語のクセ話しても通じないこと多いし javascriptは素人でも扱えるし 758 名前：デフォルトの名無しさん mailto:sage [04/12/29 00:23:38] >757 ECMAScriptスレ行け 「メジャーだから〜〜の実装こそが○○を現わす」と騙るのは不毛だから止めようぜ 759 名前：デフォルトの名無しさん mailto:sage [04/12/29 03:33:25] 誰か>>3 >>4 >>19辺りにあがってる言語の>>755みたいな違いを一覧にしろよ 話はそれからだ 760 名前：デフォルトの名無しさん mailto:sage [04/12/29 08:32:17] クラスベースでも クラスの挿げ替えができる クラスの変更がインスタンスに反映される な言語はあるでよ 761 名前：デフォルトの名無しさん mailto:sage [04/12/29 10:42:59] >>749 前半賛成、後半反対。 プロトタイプベースもクラスベースも等価であって、 どちらが優れているかは、それ以外の技術要素(型システムやメタプログラミ ング、リフレクション、例外、継続など)や処理系や開発環境との 「組み合わせの妙」のほうがずっと重要。 762 名前：Aransk [04/12/29 15:16:38] 敢えてプロトタイプベース言語に対する反論の 立場から述べます。 ttp://mput.dip.jp/?date=20030912より引用： >実行時に動的に先祖クラス(に相当するもの)が変更できます >実行時に動的にメソッド定義やメソッド除去ができます。 プログラムは作成者の意思を反映させるものという 観点からして上記の操作が動的にできるメリットって なんでしょうか？ >動的すぎてわけが分からなくなります :-) これはstaticかつpublicに卓見だと思うのです。 763 名前：デフォルトの名無しさん mailto:sage [04/12/29 15:25:46] 素人として>>762の疑問は湧くなぁ。 メリットとして上の方ではCoRが挙がってたけどそれっておまけだよな。 あとGUIのボタンとか、インスタンス固有の振る舞いが多くかつ混乱が起きにくい場合、か？ それのJavaのinterface+無名クラスとかC#のdelegateとかより優れてるトコってなんだろう？ モデルがシンプルできれい、というだけ？ 764 名前：デフォルトの名無しさん mailto:sage [04/12/29 15:26:48] どうでも良いんだけど、C# のクラスの中にデリゲート用の変数を スロットの変わりに無限個 (なお、変数名が重ならないように) 作成したとすると、 プロトタイプベースっぽくなるような気がする 765 名前：デフォルトの名無しさん mailto:sage [04/12/29 15:27:54] >>763 プログラム内で一個しか作らないオブジェクトに、わざわざ新しいクラスを作りたくない とか 766 名前：デフォルトの名無しさん mailto:sage [04/12/29 15:52:03] >>765 プログラム内で一個しか作らないモノのクラスをつくるのと プログラム内で一個しか作らないモノのオブジェクトをつくるのと、 何が違う？ 767 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:04:22] >>766 singleton でぐぐるように という誘導は置いておいて、例えば Web ページ上にボタンが配置されているときに、 そのボタンにメソッドを追加するのはプロトタイプベースのほうがやりやすいよな 768 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:08:25] 静的言語か動的言語かが決定的な分水嶺であって、 クラスが動的な存在であれば、POOもCOOも大した違いはないんじゃないかと。 COOではお仕着せのクラス機構の代わりに、POOではシンプルな委譲機構が提供されているというだけで。 POO知らずにJavaScriptやったとき、「なんじゃこの手抜きなOO機構わ。ハハハ」と思った記憶があります。 それを踏まえてPOOのメリットって言うと、どうなんだろう。 769 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:12:03] >>767 singleton くらい知ってるわヽ(`Д´)ﾉｳﾜｧｧｧーﾝ!! わざわざsingletonなんてしないで無名クラスでやりゃ、 どのみち定義書いてオブジェクトにセットするって手間は変わらんだろっつってんだよ。 おまけにJava/C#なら型チェックもしてくれるぞ。 770 名前：デフォルトの名無しさん [04/12/29 16:18:59] CLOS and MOP 最強伝説。 771 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:19:53] ダスキンの掃除用具ですか？＞クロスとモップ 772 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:20:19] >>762 プログラムは作成者の意思を反映させるものという観点からして、 オブジェクトを直接記述できるプロトタイプベースのほうが クラスを介してしか記述できないクラスベースよりも その意思を直接反映させることができる、 ということにも気付かないのかなあ。 あいかわらず過去ログでの議論にも目を通してなさそうだし。 773 名前：デフォルトの名無しさん [04/12/29 16:29:03] c++ぽくやるとすれば中間言語で… 774 名前：デフォルトの名無しさん [04/12/29 16:32:39] >>772 それはつまり、>>763の最終行でFA、ということでよろしいか？ Aranskのような脳味噌クラス漬けが大半を占める世の中ではメリットとは言えまいて。 775 名前：デフォルトの名無しさん mailto:sage [04/12/29 17:36:46] >>774 > それはつまり、>>763の最終行でFA、ということでよろしいか？ 全然違うよ。 むしろプロトタイプベースの良いところはdirty hackingな状況で発揮される。 モデルがsimple&cleanであることと、記述が直接的であることは全然別問題。 776 名前：デフォルトの名無しさん mailto:sage [04/12/29 17:41:09] >>775 クラスベースは「設計図から機械を作る」のに対し、 プロトタイプベースは「いっぱいあるジャックにプラグを色々組み合わせていく」イメージとか妄想してみると クラスベースのほうが綺麗に作れるけど、プロトタイプベースのほうがごちゃごちゃしているが簡単に作れる？ 777 名前：デフォルトの名無しさん [04/12/29 18:17:25] >>775 dirty hackingな状況で発揮されるってことは、 書ける・書けないってとこが最重要で、それもさっくり書けるところがポイントだと思うが、 >>769の通り、クラスが動的なら、クラスベースもプロトタイプベースもさほどの違いはないのではないか？ 778 名前：デフォルトの名無しさん mailto:sage [04/12/29 18:22:35] JavaのMathクラスはクラスの意味が無い 779 名前：デフォルトの名無しさん mailto:sage [04/12/29 18:23:25] >>778 ツールキットだからな 780 名前：デフォルトの名無しさん mailto:sage [04/12/29 18:25:20] >>778 class の意味は『分類』だから、別にオブジェクト指向に縛られてなくてもいいんじゃないか？ 781 名前：1 mailto:sage [04/12/29 18:45:49] 既に動いてるオブジェクトを使ってプログラミングする時なんか プロトタイプベースだと綺麗に記述できると思います。 使ったことないけどDOMで便利だっていうのはそういうことですよね。 例えばEmacs Lispなどのいじくり回す必要があるアプリレベルを叩く言語とか。 システムを一から作り上げるのはクラスベースの方がいいかもしれないけど、 システムを表面から操作するのはプロトタイプベースの方がスマートだと思います。 システムの上で別のシステムを動かすことまで考えると一概には言えませんけど。 Smalltalkがクラスベースなのはそのせいかなぁ。 システム記述とシステム操作の言語を統一することを考えた場合、 プロトタイプベースよりクラスベースの方が良さそうだということかなぁ。 それともプロトタイプベースなど考えつかなかったのか。 782 名前：デフォルトの名無しさん mailto:sage [04/12/29 18:51:42] >>781 > システムを一から作り上げるのはクラスベースの方がいいかもしれないけど、 > システムを表面から操作するのはプロトタイプベースの方がスマートだと思います。 その通りだと思う。 あるいは、記述するだけならプロトタイプベースのほうがhandyでdirectに記述できる。 が、他人に理解してもらおうと思ったらクラスベースのほうが整理しやすいんじゃないかな。 > Smalltalkがクラスベースなのはそのせいかなぁ。 > システム記述とシステム操作の言語を統一することを考えた場合、 > プロトタイプベースよりクラスベースの方が良さそうだということかなぁ。 > それともプロトタイプベースなど考えつかなかったのか。 Kay的には、例えばeToysのようにクラスベース上にインスタンスベースな環境を 構築すればいいだけという(無意識の)見切りがあったんじゃなかろうかと思う。 だが、一般のOO屋は、そこにあるクラス群こそがSmalltalkだと思ってしまった のではないかと。 783 名前：デフォルトの名無しさん [04/12/29 18:55:21] ごちゃごちゃ言わんと優れたソフトウェア&システムを作れってことだ。 思想や書き方云々は金にならん。 784 名前：デフォルトの名無しさん [04/12/29 19:50:41] ごちゃごちゃ言わんと、コードで示せ！ >>783 2chで文句垂れてても金になりませんよ。 785 名前：デフォルトの名無しさん mailto:sage [04/12/29 19:58:13] >>784 You show: theCode 786 名前：デフォルトの名無しさん mailto:sage [04/12/30 16:13:19] javascript＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ﾌﾟ(ry 787 名前：デフォルトの名無しさん mailto:sage [04/12/30 19:20:55] Ruby ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ 788 名前：デフォルトの名無しさん mailto:sage [04/12/30 20:13:59] >>787 おい、Ruby よりも低級な言語が存在していないぞ 789 名前：デフォルトの名無しさん mailto:sage [04/12/30 21:13:00] 787 名前： デフォルトの名無しさん [sage] 投稿日： 04/12/30 19:20:55 Ruby ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ 788 名前： デフォルトの名無しさん [sage] 投稿日： 04/12/30 20:13:59 >>787 おい、Ruby よりも低級な言語が存在していないぞ 790 名前：デフォルトの名無しさん mailto:sage [04/12/30 21:16:37] 787 名前： デフォルトの名無しさん [sage] 投稿日： 04/12/30 19:20:55 Ruby ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ 788 名前： デフォルトの名無しさん [sage] 投稿日： 04/12/30 20:13:59>>787 おい、Ruby よりも低級な言語が存在していないぞ 791 名前：デフォルトの名無しさん [04/12/31 08:21:43] Rubyｷﾁｶﾞｲ顔真っ赤記念晒しage 792 名前：Aransk [04/12/31 17:49:02] 無茶苦茶レベルを落として申し訳ないが Ioってどうしたら日本語通じるの？ 「Io>」プロンプトのあと色々と やってみたがどうもうまく行かない。 アドオンを付加すれば一応ユニコード OKみたいなことをHPには書いてあるよう だけど…。 793 名前：Aransk [04/12/31 19:24:13] ちょっとレベルを上げます。 どうも良く分からないんですが、プログラミング パラダイムそのものを考えた場合に 「main メソッドの喪失」 ってどうなんでしょうねぇ。 これはプロトタイプ言語だけではなく スクリプト系言語全般に言えることで すが、プログラムの構造化の観点からすれば 逆流はしてますよね。 794 名前：デフォルトの名無しさん mailto:sage [04/12/31 20:28:48] >>793 当たり前だろ？　構造化とは逆方向を行くのが関数指向や論理指向、もろもろの非手続き指向なんだし それから、構造化がプログラムの質を上げるというのは必ずしも正しいことじゃないよ 795 名前：デフォルトの名無しさん mailto:sage [04/12/31 20:43:36] ……なんか俺変な事言ったような気がする ぬるーよろ 796 名前：689 mailto:sage [04/12/31 22:00:05] >793 main メソッドが消失しているのではなく、トップレベルがmain メソッドに なっているだけのこと。 スクリプト系は頭から逐次処理されることを想定しているから、 わざわざスタート地点を指定する必要が無いだけですな。 メリット ・プログラムするときに、逐次処理部分と定義部分を分けて考える必要が無い ・処理系を作るのが（逐次処理だけで済むので）ラク デメリット ・（どの部分をあらかじめ処理していいのかのヒントが少なくなるので） 　最適化しにくい 純粋関数型でも同様だと思う。 797 名前：デフォルトの名無しさん mailto:sage [04/12/31 22:50:11] main についてはその通りだと思うが、関数型言語の中でも Haskell は main という関数を定義しないと動かないし、結局は処理系の設計者がどう考えて設 計したか、ってだけだと思うんだがな。 つうかAranskにマジレスしても無駄。

---

---

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

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