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

1 名前：デフォルトの名無しさん [03/12/08 21:30] オブジェクトを複製または継承によって生成を行う言語， プロトタイプベース・オブジェクト指向言語について語りましょうよ． 関連リンク >>2 305 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:15] GUIはオブジェクト指向の考え方が非常に良く当てはまる， 非常に稀な例だからなぁ． 306 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:20] > 実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。 なんかいやな仕事だな。 いやな客にすばやく対応できるとかじゃなく もっと明るい利点はないですか？ 307 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:27] 実行時にクラスを変更できる言語は知らないけど， クラスベースで，オブジェクトへの動的なメンバ追加を許す言語はある(はず)． メンバの動的変更はプロトタイプベースの特権ではない． 308 名前：1 mailto:sage [04/02/03 19:27] 具体例，具体例って五月蝿いやつは まずクラスベースでの具体例だせよ… クラスあるとこいういう風に綺麗に作れるけど， プロトタイプベースじゃこうはいかないだろ？ と． 309 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:36] 開発方法論のウォーターフォールvsスパイラルで やってることと同じ内容で言い争ってる？ 問題点はもう少し整理しないと。 310 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:39] >>308 プロトタイプベースでもクラスベースでも同じ書き方ができるんなら， 実行効率や型チェックの面で圧倒的にクラスベースの方がいい． 問題は，プロトタイプベースでうまく書けるが，クラスベースではうまく書けない 例がどの程度存在するか，そしてそれは必要なのか，という点． 311 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:43] >>304 > なるべく短期間で客の要求を的確に割り出すのが仕事じゃないのか。 そのためのラピッドプロトタイピング。 > ほとんどの場合、ヒアリングで解決することだし。 十分に枯れたドメインなら言葉だけでいいかもしれんけどね・・・ プロトタイプを動かしながらお客さんの指示に従って変えていくヒアリングもアリだよ。 > そりゃまぁ適当に書いたコードを使い回したりするのはマズいだろうけど、 > キチンとしたコードなら一向に構わないと思うんだけど。具体例きぼんぬ。 プロトタイピングはキチンとしたコードを書くのが目的ではなくて、 お客さんの要求を引き出すために必要十分に動けばいい。 むしろエラー処理やスケーラビリティがキチンとしたコードを書くために プロトタイプ作成が遅くなるのでは本末転倒になりかねない。 それよりも、目の前にいるお客さんに一秒でも早く動きを見せたほうがいい。 もちろん本番のコードはキチンと書く。当然だよね。 具体例は、俺が実際に経験したプロジェクトを具体的に書くと 狭い業界だからお客さんや俺自身が特定されかねないんで、勘弁。 312 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:43] 個人的には，>>267はプロトタイプベースのデメリットだとおもう． 313 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:49] 客への対応とかはもうどうでもいいよ…． 314 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:51] 結局ここでもLISPが最強ということだな。 315 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:08] Lisp は歴史上の通過点として、プロトタイプベース言語の中でも大きな位置を占めているね。 316 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:15] 記述能力については、プロトタイプ言語は（クラスレスであるという）その本質的な特徴よりも、 大抵の実装でオブジェクトがスロット付きであって、メソッをド含むスロットの追加・削除が 動的に可能だということの方が支配的だと思うな。 317 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:22] >>316 良い事言った！ 俺もそう思うよ。 318 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:25] >>316 同意．ただ，>>307をどう見るかですな． 319 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:36] クラスが有るか無いかは（この文脈では）それ程大きな問題では無いから、当然 hybrid な 言語があっても良いでしょうね。Ruby みたいな。 320 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:43] 結局ここでもRubyが最強ということだな。 321 名前：デフォルトの名無しさん mailto:sage [04/02/03 21:14] 文法としてフレームを直接表記できる言語は、なんかやる気でるよね。。 （gcc / g++ でもフィールドを陽に指定する初期化リストなんかが使えるけど）。 ハイブリッドはアリだと思うなあ。フレームに対するメソッドインボケーションは NewtonScript / Self 式、そうでない、構造体に対しては C++ 式とか。 純粋 prototype ベース（フレーム理論ベース）言語だと、 Complex とか Rect のような小さな構造でオーバーヘッドが大き過ぎ（やる気でない）。 322 名前：デフォルトの名無しさん mailto:sage [04/02/03 23:03] で、なんで Ruby が最強なのか説明してくれ。 323 名前：デフォルトの名無しさん mailto:sage [04/02/03 23:50] >>322 やめろ．荒れる． 324 名前：デフォルトの名無しさん mailto:sage [04/02/04 02:32] クラスの有無は重要じゃないんだよね。クラス指向の人は納得しないだろうけど。 325 名前：デフォルトの名無しさん mailto:sage [04/02/04 03:02] >>324 漏れはクラスがあってもなくても、どっちでもいいけど、 クラス無しでオブジェクトを記述する方法はあったほうがいい派。 326 名前：デフォルトの名無しさん mailto:sage [04/02/04 03:10] クラスがあっちゃ出来ないことって何よ？ 結局何も無いだろ？ 327 名前：デフォルトの名無しさん mailto:sage [04/02/04 03:20] >>326 だから有る無しじゃないんだってば、おとっつぁん。 328 名前：デフォルトの名無しさん mailto:sage [04/02/04 04:03] >>326 「出来ること/出来ないこと」という論点では、 ほとんどのプログラミング言語はチューリング機械相当ということで 同等だ罠。 329 名前：デフォルトの名無しさん mailto:sage [04/02/04 04:05] オブジェクト指向の神髄はメッセージングにあると思う。で、動的にスロットの参照先を 変更出来れば、より柔軟にメッセージを送受信出来るので嬉しい。 330 名前：デフォルトの名無しさん mailto:sage [04/02/04 10:35] クラスベース言語の言い分としては、設計から実装へと シームレスに落としこめるというものがある。 その辺り、プロトタイプベース言語やLispなどでは、 プログラマの経験則に多くを負っている。開発手法との 関連付けも弱い。 分析、設計、実装を繰り返すスパイラルな開発においては、 個人的にはプロトタイプベース言語の方が向いているように 思うが、Javaにはそこでもかなりのセオリーや実績がある。 開発手法がプログラミング言語非依存なものであることから 考えて、プロトタイプベース言語が開発のサイクルを回す上で 優れているのなら、実績があってもいいはず。Java派の 人の言う「具体例」とはこういうことだと思う。 まあ言語自体がマイナーだから具体例なんてないけどね（ｗ 俺はEmacsが好きだし、プロトタイプ言語にも活躍の場は 当然あると思うけど、それは優れたプログラマが小人数で 開発するケースにしか使えないと思う。 なお、使い捨てのデモアプリケーションを作るという意味での プロトタイプ言語はここでは考えていません。 331 名前：デフォルトの名無しさん mailto:sage [04/02/04 12:55] 動的かどうか、柔軟かどうかはプロトタイプベースかクラスベースかとは直接関係ないんでしょ? (プロトタイプベースのほうが柔軟にはしやすいのだろうけど) じゃあ、あとはどっちを使うかは個々人の流儀の問題で、ただの好き好きに過ぎないって事ですか? 世の中でクラスベースが主流なのは何故? 処理系を実装しやすいのか? 静的な型チェックを厳密にできるからか? 単なる歴史的な経緯か? 世の中をclassifyしたがる人間の性か? 332 名前：デフォルトの名無しさん mailto:sage [04/02/04 13:09] prototype-based の利点が活きるのは、設計が固まる前だと思う。 理想的な water fall で、固まった設計を実装するだけなら、静的な class-based のほうが強そう。 この場合、設計担当の人向きかな、とか。 333 名前：デフォルトの名無しさん mailto:sage [04/02/04 13:26] >>331 世の中でクラスベースが主流なのは何故? たまたま大手のソフトウェアベンダが採用したっていう 偶然的理由によるところも大きいんじゃないの？ >>332 開発方法論は言語ニュートラルなものとして作られてるけど その実はかなり関係してるような印象を受けてる。 最近のものは殆どといっていい程、Java、もしくはC(オプソ？)を 想定したものばかりに見えるけど。。。 334 名前：デフォルトの名無しさん mailto:sage [04/02/04 13:31] >>308 プロトタイプベースの利点も分からないのに、クラスベースではこうやる、 なんて出せるわけないだろ。 >>332 >理想的なwaterfallで、固まった設計を実装するだけなら、 >静的なclass-basedのほうが強そう。 クラスベースでwaterfallじゃない開発スタイルも存在すると思うんだけど。 >>>333が言うように、JavaとかCを想定したものが多いけどね。 クラスベースの方が直感的で分かりやすいからじゃないかな。 >>1はお怒りのようだからあんまり言いたくないけど、具体例が出てこないから プロトタイプベースの言語や、開発スタイルがどういうモノなのかピンと来ないし。 335 名前：333 mailto:sage [04/02/04 13:35] 途中で送信しちゃった。 prototype-based言語が有用だとJava派の人に対して主張するなら、 具体的な事例はまだないので、その代りに具体的な開発のシナリオを 出す必要があると思うね。開発方法論のセオリーも含めてさ。 言語だけ純粋に見て、その審美性だけで判断するようなことをしても 現実には全然訴えかけるものがないよ。美的観点だけで普及するなら 関数型言語がとっくに広まってるだろうし。 336 名前：デフォルトの名無しさん mailto:sage [04/02/04 14:17] >>335 > prototype-based言語が有用だとJava派の人に対して主張するなら、 > 具体的な事例はまだないので、 をい、>>282さんがあれだけ丁寧に・・・>>332さんも同じ主旨の事を言ってるが、 両方無視かいな。 そもそもJava派って何なんだよ。Java以外のクラスベースはカヤの外かいな。 動的型付クラスベース派はどうすりゃいいんだよ(藁 337 名前：デフォルトの名無しさん mailto:sage [04/02/04 15:00] >>336 具体的な例が(ry…って意見がいくつも出てるんだから、十分な情報じゃないんだろ。 338 名前：デフォルトの名無しさん mailto:sage [04/02/04 16:36] んー。 言語の実践的な有用性については、大手ベンダーがその環境向けの標準開発環境として 採用するかどうかということだけが問題だけなんで、このスレ的にはどうだろうか。。 ってのは333で既出か。 WEB 方面では JavaScript の他に Macromedia Flash の ActionScript でも prototype.__proto__ による プロトタイプ継承が使われてますね(ECMA Script準拠なんで当然だけど)。 339 名前：デフォルトの名無しさん mailto:sage [04/02/04 17:51] >>338 既出だがECMAScriptには__proto__なんてないし、ActionScriptでも6.0から __proto__は非推奨属性だしそもそも最近のActionScriptはクラス指向だし。。。 340 名前：1 [04/02/04 18:41] >>334 多分このスレに書き込んでいるほとんどの人はプロトタイプベースOOPL を使った開発なんてまともにやったことないでしょう．(私も含めて) Googleでちょっと検索してみればわかると思うけど，ECMAScript以外は 解説サイトすらなかなか見つからない．見つかったら是非教えて欲しい． そんな状況で圧倒的多数のクラスベース派がプロトタイプベースの明確な 利点がわかる具体例を示せなんて言ってたって時間の無駄だと思う． >プロトタイプベースの言語や、開発スタイルがどういうモノなのかピンと来ないし。 それはそうでしょう．私も知りたい． 資料もないし，経験者も少ないし． 自分で触ってみるしかないですよ． 触ってみてこれはいいんじゃないかって思ったり やっぱり使えないっと思うことがあるなら， そういった情報を共有しようじゃないですか． 341 名前：デフォルトの名無しさん mailto:sage [04/02/04 18:44] 要するに、まだ実用例は無いってことね。 342 名前：デフォルトの名無しさん mailto:sage [04/02/04 20:21] Newton Message Pad 自体は商業的に失敗したわけだけど、 一応立派な実用例ではあると思う。 343 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:01] >>330 >それは優れたプログラマが小人数で >開発するケースにしか使えないと思う。 それで良いんじゃないの? 使い道が分からない人間が無理に使う必要はないでしょ。 >>335 >prototype-based言語が有用だとJava派の人に対して主張するなら、 どちらかというと、Java 派の人にはどこか他所に行って欲しい。 というか過去レス嫁。審美性とか言っちゃって痛杉。 344 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:09] つまり prototype-based を使ってる俺は優れたプログラマなんですよ、と言いたいわけですね？ 345 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:18] んにゃ。クラスベース言語に疑問を持たない人が興味を持っても、得る物は少ないから どっか行けと言いたいだけ。 346 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:33] 疑問を持ってるから来てるんだけど、具体例出してくれないんだもん。 347 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:39] クラスのない世界に興味ある椰子がネ申を囲ってマターリするスレでしょ。 クラスマンセーの人に押しつけもせず、クラスがないデメリットも含めて 冷静に語り合うスレでよいと思われ。 348 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:43] >>346 処理系の一つも自分で動かしてみようという気はないのか? 自分の疑問に思ったところを他の言語で実装し直してみれば立派な具体例だろう。 その言語はプロトタイプベースである必要も無い。 349 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:46] >>348 実際にやってみて「別にクラスベースでいいじゃん」と思っただけだが。 350 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:49] >>349 じゃぁクラスベースで良いんじゃない? 迷わず逝けよ。 351 名前：デフォルトの名無しさん mailto:sage [04/02/04 22:03] >>346 どんな疑問ですか？ 煽りだけど、まじめに答えてくれればなにかのネタになるかも。 352 名前：デフォルトの名無しさん mailto:sage [04/02/04 22:03] OSchemeが面白そうだからやってみようと思ったら、ダウソできない・・ どっかで落とせませんか？ 353 名前：デフォルトの名無しさん mailto:sage [04/02/04 22:07] C#のdelegateって、プロトタイプとうかスロットぽい？ 354 名前：デフォルトの名無しさん mailto:sage [04/02/04 22:12] >>352 古いし、動かしてみてないけど。他の Scheme リポジトリも見てみて。 ttp://ftp.cs.indiana.edu/pub/scheme-repository/imp/ 355 名前：352 mailto:sage [04/02/04 22:14] 自己解決 こっから落とせた www.cs.indiana.edu/scheme-repository/imp.html 356 名前：352 mailto:sage [04/02/04 22:15] >>354 ありがとう 同じとこだな（ｗ 357 名前：1 mailto:sage [04/02/04 22:43] >>353 スロットっていうと名前で参照できるメンバを動的に追加・削除できるようなイメージがあるけど． マルチキャストデリゲートは機能の追加・削除が行えるけど名前に関しては静的だよね． 358 名前：1 mailto:sage [04/02/04 22:52] class Hoge { public delegate void PrintDelegate(); public PrintDelegate Print; } Hoge hoge = new Hoge(); hoge.Print += new PrintDelegate(_PrintHello); hoge.Print += new PrintDelegate(_PrintBye); hoge.Print(); スロットだとこんな感じ？ class Hoge { } hoge.PrintHello = _PrintHello; hoge.PrintBye = _PrintBye; hoge.PrintHello(); hoge.PrintBye(); 359 名前：デフォルトの名無しさん mailto:sage [04/02/05 01:41] ん。 んで slot の場合には、例えば if a.hasSlot('asText') then 　write( a.asText() ); else 　write( "unknown object" ); みたいに、「無い」ということも積極的に使うスタイルになります。 DOM の attribute と似てる。 360 名前：デフォルトの名無しさん mailto:sage [04/02/05 13:42] 世の中には市場の失敗というのもありうるが、だいたいにおいて市場は良いものの方を選択するから、 結局のところ現状のプロトタイプベースより現状のクラスベースのほうが使いやすいのかも。 (一般的なプログラマにとっては) 一部の神にとっては全てを思い通りに動的にできるプロトタイプベースのほうがいいのかもしれんが。 361 名前：デフォルトの名無しさん mailto:sage [04/02/05 14:27] >>340 > 多分このスレに書き込んでいるほとんどの人はプロトタイプベースOOPL > を使った開発なんてまともにやったことないでしょう．(私も含めて) プロトタイプベースは言語よりもむしろ環境として生きるものだと思うなあ。 スクリプトもいいけど、やっぱオブジェクトを記述するメディアとしては テキストというのは不適合っつーかさ。 >>342 Smalltalk系で言えば、PARTSとかVisualSmalltalkとかあったなあ。 これはクラスベースの環境の上にプロトタイプベース環境を構築したものだから、 ハイブリッドだな。 362 名前：デフォルトの名無しさん mailto:sage [04/02/05 14:44] >>360 > 結局のところ現状のプロトタイプベースより現状のクラスベースのほうが使いやすいのかも。 むしろ、現状を肯定する材料を無意識に探している人も多いんじゃないかと思われ。 クラスベースのほうがいいという理由として最適化を出した人がいるけど、 それで何パーセントパフォーマンスが上がるのか。その何パーセントかが クリティカルになるシステムが一体どれだけあるのか。 クラスで整理したほうがいいと言いながら、 後になってから1つのクラスを2つのサブクラスに分割する時の手間は 「仕方ない」で済ませてしまう。動的型付ならともかく、静的型付で新しい サブクラスに応じて型体系をきちんと見直して、インターフェイス型の 定義を洗い直して変数やメソッドの型を適切に修正したりするのは結構 無視できない量の作業のはずなのに。 そういったことを「言語のために負っている手間」と認識せずに 「本質的に仕方ないこと」と看倣している限りは、周りが皆動いてからで ないと動かないんだろうな。 363 名前：デフォルトの名無しさん mailto:sage [04/02/05 15:05] >362 そういったクラスによるデメリットも、プロトタイプベースの動的さ故に生まれるカオスよりは マシだということなのかもしれない。 普通のプログラマには枠が有ったほうがいいのかも。あまりに動的だと乗りこなせない。 世の中、Smalltalk, C++, Java とクラスベースで来てるから、 単に流れでクラスベースなだけかもしれないけど。 Kay, Stroustrup, Gosling は何故クラスベースを選択したんだろう。好み? 364 名前：デフォルトの名無しさん mailto:sage [04/02/05 15:11] 正直、インターフェース型さえしっかり設計されてれば、 動的だろうが静的だろうが、クラスだろうがプロトタイプだろうが関係ないような。 365 名前：デフォルトの名無しさん mailto:sage [04/02/05 15:59] >>363 > Kay, Stroustrup, Gosling は何故クラスベースを選択したんだろう。好み? 他の2人はともかく、Alan KayはSqueakのMorphでインスタンスベース風な 環境に取り組んでいるのですが・・・ 366 名前：デフォルトの名無しさん mailto:sage [04/02/05 16:19] >>362 ・クラスベースの方が数倍は速い．(実行速度のことね) ・型付けされていればバグが減る． ちなみに俺はクラスベースの方がいいとは思ってないが， クラスベース<プロトタイプベースとも思ってない． 367 名前：デフォルトの名無しさん mailto:sage [04/02/05 16:41] >>366 > ・クラスベースの方が数倍は速い．(実行速度のことね) これは具体的に何と何の比較？SelfとSmalltalkでこの差が出る？ それともSelfとC++？ どっちかっつーと、クラスベース/プロトタイプベースの比較以上に プリミティブ型や演算子などの扱いとかのほうが 直接パフォーマンスに効いてくるんじゃないかと思うが。 あと、VMかネイティブコンパイラかのほうが大きいかもしれない。 > ・型付けされていればバグが減る． プロトタイプベースでも静的型付は可能でしょ。 ただ単に、プロトタイプベースの良さを引き出すためには 多くの言語が動的型付を採用しているというだけの話で。 実際、スロットの動的追加はsubtypingとして元の型のままと看倣せるし、 スロットの変更についても、代入と同様の型チェックを実行するだけの話では？ スロットの削除はコピー生成時からあるスロットに対してのみ削除を禁止して、 動的に追加されたスロットは削除してもいいと思うし。 368 名前：367 mailto:sage [04/02/05 16:55] つーか、このスレって (1) 既存のオブジェクト指向プログラミング言語/環境の比較として、 　　クラスベースとプロトタイプベースのものに分けて比較する。 (2) オブジェクト指向プログラミング言語/環境を設計するための 　　技術要素としてのクラスベース/プロトタイプベースの利点/欠点を 　　比較する。 のうち、どっちなんだろ。 最初のころは「プロトタイプベース・スクリプト言語へのクラス導入ハンターイ」 という意見があったんで(2)もアリだと思っていたのだが、 もし(1)のみが焦点ならば、>>367はとんでもなく的外れになるわけだが。 369 名前：デフォルトの名無しさん mailto:sage [04/02/05 17:20] つか >実際、スロットの動的追加はsubtypingとして元の型のままと看倣せるし、 動的に追加したら、結局、動的に束縛しなきゃならないわけで、 静的型チェックによる速度向上なんか望めないような。。。 370 名前：デフォルトの名無しさん mailto:sage [04/02/05 17:22] んー漏れは >>1 にあるように; >オブジェクトを複製または継承によって生成を行う言語， >プロトタイプベース・オブジェクト指向言語について語りましょうよ． という趣旨で参加してますた。 だからクラス付き言語との比較の話は「スレ違いだけど、まぁ仕方ないか」って感じで。 371 名前：デフォルトの名無しさん mailto:sage [04/02/05 17:29] 漏れはクラスベースかプロトタイプベースかは、言語の優劣のような ものとは無関係だと思うね。 「オブジェクト指向」を純化させると「プロトタイプベース」になる というのは理解できるけれども、クラスという仕組みはやはり便利だし、 「プロトタイプベース」であることの利点を述べているつもりでも、 実はその言語が「動的変更をどれだけ許すか？」を語っているだけ じゃないかと思うことが良くある。 そして「動的vs静的」は古来「柔軟性vs効率」の戦いになって不毛。 372 名前：デフォルトの名無しさん mailto:sage [04/02/05 18:02] JavaScript でプロトタイプベースなOOやってみてるウェブサイトってないですか? ttp://member.nifty.ne.jp/masarl/article/js-oop.html ttp://www.tokumaru.org/JavaScript/ 以外で。 JavaScriptなのは他にプロトタイプベース言語知らないから。 ドキュメント豊富なのってこいつくらいだよね。SelfだのNewtonScriptだのは全然見かけないし 373 名前：1 mailto:sage [04/02/05 19:16] >>368 >>370 スレ違いではないと思うけど，あまりクラスベースと比較ばっかしてても >>371の言う通りではないかなぁ． # というか個人的につまらないだけですが…w 374 名前：デフォルトの名無しさん mailto:sage [04/02/05 19:54] >>371 クラスベースでも動的変更は出来るから， 「クラスベース: 静的」「プロトタイプベース: 動的」とは言えない． プロトタイプベースとクラスベースの本質的違いはそこではない． 375 名前：デフォルトの名無しさん mailto:sage [04/02/05 22:20] 本質とか純化とか優れているとかじゃなくて、もちっと具体的にうれしいのか 説明してくれると嬉しいんだが。RAD だのオブジェクトを触って変更できるって 動的言語なら大抵そうじゃない？オブジェクトを触るっていうけど、別にｸﾗｽﾍﾞｰｽ だって動的言語なら大抵オブジェクトを操作できますよね？一オブジェクトだけ メソッド追加/変更とか。 理論的にシンプル（概念が少ないから）だから…というくらいしかわかんないなぁ。 で、とりあえずやってみりゃ分かるだろと思って Self ってのを試そうと 思ったんだが x86 じゃ動かないみたいだし。結局 2ch で聞いてしまうわけだ…。 376 名前：デフォルトの名無しさん mailto:sage [04/02/05 22:36] 動的なクラスベースっていうと・・ Smalltalk以外には何があるの? 377 名前：デフォルトの名無しさん mailto:sage [04/02/05 22:51] そんなのいっぱいあるんじゃねーの？スクリプト系とか。Lisp 系も大抵そうだろう。 違いとかじゃなくてクラスベースだとﾏｽﾞｰだけどプロトタイプだとｳﾏｰな点を指摘して やればいいだけんじゃないのかと思われ。 378 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:10] １オブジェクトだけメソッド追加/変更なんて出来るクラスベース言語ってあるのかな。。 クラス自体を新しく作って、オブジェクトのクラスを変更するんならともかく。 漏れ的にはプロトタイプベースの言語でも大抵なんでもできるんじゃないの、って立場なんで、 逆に 375 の人に「なんでクラス付き言語の方がいいの？」ってのを具体的に聞いてみたい。 広く使われていてライブラリが充実しているので Java がいい、とか、実行速度が速くて ジェネリックスがやりやすいので C++ がいい、とかさ。 379 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:13] もういっちょ。 プロトタイプベース言語はクラスベース言語の何かについての反省から生まれてきたわけではないし、 誰も「喪前らクラスベース言語はマズイですよ」とも言ってないわけだから、 「クラスベースだとマズー」→「プロトタイプベース言語でウマー」ってのが無きゃならない・あるはずだ、 ということはないと思うんだけど。 380 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:25] >>375 > だって動的言語なら大抵オブジェクトを操作できますよね？一オブジェクトだけ > メソッド追加/変更とか。 クラスベースできるけどその言語本来が狙っているやり方じゃないような。 純粋にクラスベースで1つのオブジェクトだけメソッドやイ変数を追加しようとしたら、 そのために動的にクラスを生成してそのクラスのインスタンスに化けるという操作 が必要になる。 じゃあその動的に生成したクラスの名前はどうするってこととか、どっかシステム中 に元のクラスを参照している部分があったらそこも変更しなきゃいけないのかとか、 結構面倒なことになる。 で、例えばクラス名は適当に番号か何かを付けて自動的に名前を生成しても、 そんな適当な名前がクラスライブラリに混入することはクラスベースで想定していた 「良いプログラミング」とはかけ離れたものになるんじゃないかな？ そういうクラス絡みの「やり難さ」を取り除くには、クラスでの定義とは独立して メソッドや変数を追加できる機構が必要になると思われ。 俺的には、そういう機構さえあれば、別にクラスが存在していてもいいと思ってる。 381 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:31] あ、そうなのか！どうやら漏れはとんでもない勘違いをしていたようだ…。 てっきり、クラスベースのなにかを反省して出来たのかと思ったけど、 そうじゃないわけね。うーむ、とりあえず試してみたいがなんか x86 で 動くやつのオススメをキボンヌ。 > １オブジェクトだけメソッド追加/変更なんて出来るクラスベース言語ってあるのかな 例えば CLOS ではできたYO。基本はクラス単位だけどオブジェクト単位でも定義できる。 ついでにメソッドコンビネーションで特定のメソッドの前後に処理を追加するとかもできるのが面白い と思った。つまり特定のオブジェクトのあるメソッドの前にだけ処理を挿入とかできるｳﾏｰ。 ｳﾏｰな例： このｵﾌﾞｼﾞｪｸﾄはﾕｰｻﾞｰが触ったやつだから消えるときは知らせよう→削除しますた表示をｵﾌﾞｼﾞｪｸﾄに追加 382 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:37] ま、現実的な市場のニーズはないんだけどな。 漏れのような現場の土方には思考の訓練の道具ってだけだな 383 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:37] >>369 > 動的に追加したら、結局、動的に束縛しなきゃならないわけで、 > 静的型チェックによる速度向上なんか望めないような。。。 いや、他のオブジェクトのメソッドからは、追加したメソッドは叩けないだろ。 静的型チェックしているから。 動的に追加したスロットは、一緒に動的に上書き変更したメソッドの中からしか 叩けないんじゃないかな。 で、それらのスロットを取り除く時には動的チェックするか、あるいは 一緒に動的に追加したスロット群全部をいっぺんに取り除くことにする って感じでどうよ？ かなり窮屈なプロトタイプベースだが(苦 384 名前：381 mailto:sage [04/02/05 23:40] >純粋にクラスベースで1つのオブジェクトだけメソッドやイ変数を追加しようとしたら、 >そのために動的にクラスを生成してそのクラスのインスタンスに化けるという操作 >が必要になる。 そんなことは無かったと思うけど…。 (defmethod hoge ((self クラス名)) ....) (defmethod hoge ((self (eql オブジェクト))) ...) こんだけなんで、単にメソッド検索時にオブジェクト＞クラスな 優先順位になってただけじゃないかなと思われ。 でもクラスがどうのとかはいいからプロトタイプベースの処理系を オススメしてくれょぅ。触ってみたいんだよぅ。Self が動かなくて 悔しいんだよぅ。x86 で動かせるやつ。OS は Win か Linux か *BSD くらいで。 385 名前：デフォルトの名無しさん [04/02/05 23:42] JavaScript 386 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:48] >>381 プロトタイプベース言語は、オブジェクト指向言語の一派というよりも、 ミンスキーのフレーム理論の直接の形式化で、 「オブジェクト」ではなく「フレーム」を基本的なデータ構造としています。 ttp://www.symlab.sys.i.kyoto-u.ac.jp/lecture/ai/ai.PDF のp38あたりからを参照。 387 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:50] それがオススメですか。んじゃ遊んでみます。 一応年のため聞くけど、処理系は IE とか Mozilla でいいんですよね？ 388 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:53] >>384 上の方にリンクが載っているが、Io とか Cecil なら x86 でも動くはず。 Win で Cecil 動かしてる人がいるから参考まで。 ttp://www.kmonos.net/alang/etc/cecil.php 389 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:54] >387ってずいぶん信じやすい香具師なんだな。 390 名前：デフォルトの名無しさん mailto:sage [04/02/05 23:56] ん。すくなくとも Self の論文は Smalltalk を引き合いにクラスベースの不自然さを 淡々と説いているが…？　ただ、結果としてはこのスタンスがまずかった。 オブジェクトベース（aka プロトタイプベース）がまるでクラスベースの対局だという ような考え方を一般に植え付けてしまったから。 プロトタイプベースって言葉が悪いんだよね。おそらくここで意見を交わし合うべきは オブジェクトベース（あるいはクラスを意識するならインスタンスベース）のオブジェクト vs クラスベースのオブジェクトなのであろうかと思うのですが、いかがでしょうか？＞1さん つまり、オブジェクトが自由に値スロットやメソッドスロットを追加できるとき、どんな メリット（やデメリット）があるのかとか、スロットへのアクセスにはどんな方法がベターか とか、そんな話で盛り上がった方がおもしろいと、まあ、そんなふうに思うわけです。 プロトタイプベースとくくってしまうと、オブジェクトの移譲先としてプロトタイプが良いか、 クラスが良いかという結局、好みの問題に終始してしまうので不毛かなと。 391 名前：1 mailto:sage [04/02/05 23:56] >>381 ここにあるSelfのcygwin版，動かないんだよねぇ… www.gliebe.de/self/index.html とりあえず，Cecilなんてどうでしょうか？ www.cs.washington.edu/research/projects/cecil/www/Release/ Interpreterをダウンロードして展開すればすぐに遊べますよ． ここでも見ながら→www.kmonos.net/alang/etc/cecil.php 俺はまだほとんど使ってないけど…コレはかなり楽しそう． 392 名前：1 mailto:sage [04/02/06 00:03] >>388 マッタリしてたら被ってしまった．ゴメン． つかレス速っw >>390 >プロトタイプベースって言葉が悪いんだよね。おそらくここで意見を交わし合うべきは >オブジェクトベース（あるいはクラスを意識するならインスタンスベース）のオブジェクト vs >クラスベースのオブジェクトなのであろうかと思うのですが、いかがでしょうか？＞1さん 激しく同意です． ただ私は無知なのでなかなか積極的に話題振ったりできませんが… 393 名前：デフォルトの名無しさん mailto:sage [04/02/06 00:08] なんというか，クラスベースよりプロトタイプベースの方が純粋にオブジェクト指向 してるとは思えないなぁ． クラスがない方が自然なの気がするけど，それ以上にプロトタイプのチェインは 不自然な概念だと思う． 394 名前：デフォルトの名無しさん mailto:sage [04/02/06 00:10] 開発環境を聞こうと再び 2ch を覗いたら、なんだ、他にもいっぱいあるじゃないか。 >>389 ちょっと前でも JavaScript って話だったじゃないか……正直 age に騙された。 お前らいい香具師らじゃないか。遊んでみるYO!! で、>>386 のを脳内解釈したところ、 ×クラスベースがあってそれをほにゃほにゃしてプロトタイプベースができた ○プロトタイプベースを実現した。で、クラスと比較して〜 という理解でいいのかな。 395 名前：デフォルトの名無しさん mailto:sage [04/02/06 00:16] まず，純粋な(クラスもプロトタイプチェインもない)オブジェクトがあって， でもそれでは，1つ1つのオブジェクトが同じメソッドをバラバラに持ってるのは 効率が悪いから，プロトタイプやらクラスやらが導入されたんじゃないの? 396 名前：デフォルトの名無しさん mailto:sage [04/02/06 00:21] >>390 と >>392 に同意 やっぱ焦点はオブジェクト単位のスロット管理のpros/consだわな。 つまり>>384さんの流れで言うと、CLOSもインスタンスベースとしての機能「も」 持っているわけで。 397 名前：デフォルトの名無しさん mailto:sage [04/02/06 00:23] >>384 何度か出ているけど、CLOS をクラスベースの引き合いに出すのは混乱するから やめたほうがよいと思いますよ。CLOS のオブジェクトは、スロットこそクラスベース のオブジェクトと同様にクラスを鋳型にしていますが、メソッドのほうは総称関数という まったく別の機構で扱われているわけで、誤解を恐れずいうなら、これは抽象データ型 だとかオブジェクト指向とかいった次元を超越した機構なわけですから。 398 名前：380 mailto:sage [04/02/06 00:35] >>384 まぎらわしい書き方してすまんです。>>380での「純粋にクラスベースで」とは、 「クラスが管理しているスロット定義情報のみで」という意味のつもりでした。 ので、>>834で挙げてもらったCLOSでの例は「純粋にクラスベースで」には 含めないつもりでした。 で、>>381に挙げてもらった例には大枠で賛成です。 特に、言語レベルでbeforeやafterが使えるのはイイねえ。 399 名前：380 mailto:sage [04/02/06 00:43] >>390 > つまり、オブジェクトが自由に値スロットやメソッドスロットを追加できるとき、どんな > メリット（やデメリット）があるのかとか、スロットへのアクセスにはどんな方法がベターか > とか、そんな話で盛り上がった方がおもしろいと、まあ、そんなふうに思うわけです。 もうちょい厳密に言うと、それを言語仕様または処理系レベルでサポートすることの メリット/デメリットということで、どうでしょうか？ そういうオブジェクトを構築できるかどうかということになると、 クロージャを扱える言語/処理系ならば、そういうクラス/オブジェクトを ユーザの手で作ることができるわけで、それではむしろデザインパターンと 変わらなくなるような気がするので。 400 名前：380 mailto:sage [04/02/06 00:44] >>397 > メソッドのほうは総称関数という > まったく別の機構で扱われているわけで、誤解を恐れずいうなら、これは抽象データ型 > だとかオブジェクト指向とかいった次元を超越した機構なわけですから。 でもマルチメソッド萌え・・・スレ違いスマソ。 401 名前：デフォルトの名無しさん mailto:sage [04/02/06 01:05] >>399 まあ、それは言わずもがなでしょう。オブジェクト指向におけるオブジェクトの オールマイティ性（と、同時にそれが苦手とすること）ってのは Smalltalk システムが 早々と明らかにしてしまっていますから、ことさらにここでそれを強調する必要もなかろうかと。 そんなことを言い出したら、Lisp 屋さんが出てきて、そんなのオブジェクトなんか使わんでも 俺たちならもっと巧くやれる！ってなことになりかねない(笑)。 402 名前：デフォルトの名無しさん mailto:sage [04/02/06 01:11] >>399 スレの流れ的には大賛成だが、 >クロージャを扱える言語/処理系ならば、そういうクラス/オブジェクトを >ユーザの手で作ることができるわけで、 こっちの方が超ステキ！（ｷﾗﾝ 403 名前：デフォルトの名無しさん mailto:sage [04/02/06 12:20] >>207 Smalltalkでプロトタイプベースとは、おめでてぇや。 Selfが動くVMイメージ持ってるの？ 404 名前：デフォルトの名無しさん [04/02/06 12:36] >>402 禿同 405 名前：デフォルトの名無しさん mailto:sage [04/02/06 14:08] でもクロージャでオブジェクト作るの結構メンドイんだよな．

---

---

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

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