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

1 名前：デフォルトの名無しさん [03/12/08 21:30] オブジェクトを複製または継承によって生成を行う言語， プロトタイプベース・オブジェクト指向言語について語りましょうよ． 関連リンク >>2 267 名前：デフォルトの名無しさん mailto:sage [04/02/01 21:38] そうかなぁ．継承関係はあっても，モノとしては全然関係ないobjectどうしが 影響し合うするのは良くないと思うけどなぁ． 268 名前：デフォルトの名無しさん mailto:sage [04/02/01 21:45] >>267 その、「良くないと思う」レベルが classベースと、 prototypeベースと、 なんも無しと、 で違うだけだよ。 269 名前：デフォルトの名無しさん mailto:sage [04/02/01 22:02] >>268 影響し合うのはprototype-basedだけじゃない? 270 名前：263 mailto:sage [04/02/01 23:20] >>269 クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑 271 名前：デフォルトの名無しさん mailto:sage [04/02/02 09:20] >>270 > クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑 そういう言語もアリだと思うけど。 instance creationした瞬間のclassがそのobjectのclassってことでしょ？ 272 名前：デフォルトの名無しさん mailto:sage [04/02/02 17:59] 多くのクラスベースな言語では，実行時にクラス変更なんて出来ないし， 出来たとしても，>>271のようになるのが自然だと思う． 273 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:33] >>272 > 出来たとしても，>>271のようになるのが自然だと思う． そんなこたーない。普通はクラスを変更したらインスタンスも変更される。 274 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:47] 普通はって、普通は実行時にクラスを変えられないような。 275 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:52] >>274 普通はって、「出来たとしても」という条件を満たした上での「普通は」でしょ。 文脈からいって。 276 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:56] 「普通は」が含まれている文章は、普通、普通でないことを言っている。 277 名前：デフォルトの名無しさん mailto:sage [04/02/03 01:00] すみませんが、どなたかプロトタイプならではって例をﾋﾞｼっと出して利点 を説明してくれませんか？ 278 名前：デフォルトの名無しさん mailto:sage [04/02/03 01:06] >>275 それはそうなんだけど、普通はって言うほどサンプルが無い気がして。 メソッドサーチの時にクラスをルックアップするのが普通の実装だから、クラスを変更 したらインスタンスも変更されるでしょうって事かな。 279 名前：デフォルトの名無しさん mailto:sage [04/02/03 01:24] それって「君の普通」でしょ？ 280 名前：デフォルトの名無しさん mailto:sage [04/02/03 01:32] そんなに実行時にクラスを変更出来る言語あったっけか。それなら済まない。 281 名前：デフォルトの名無しさん mailto:sage [04/02/03 02:22] >>277 実務での使用だと利点は無い。 なのでみんなクラスベースを使ってる。 282 名前：デフォルトの名無しさん mailto:sage [04/02/03 03:20] >>277 rapid prototyping的に、モノを動かしながら要求分析する時とか。 283 名前：デフォルトの名無しさん mailto:sage [04/02/03 08:35] いやだから、具体的に 284 名前：デフォルトの名無しさん mailto:sage [04/02/03 09:04] >>283 いくつかオブジェクトは出てきているけど どれとどれが似ていて、どれとどれがどう関連していて どのオブジェクトがどんな情報を持っているのかはっきりしていない状況では、 クラスを通して間接的にオブジェクトの振舞いを変えていくよりも、 目の前にあるオブジェクトを直接イジれたほうがやりやすい。 特にユーザーインターフェースデザインでは効果的。 クラスベースよりもずっとオブジェクトを直接触っている感覚があるし、 お客さんにもわかりやすい。 そうやって、お互いの理解を深めた上でクラスベースの分析設計に入ればいい。 これ以上は自分で体験してもらわないことには、言葉で伝えるのは難しい。 Smalltalk上にプロトタイプベースな環境を構築したものはいくつかあるから、 どれか試してみるといい。 まあ、今でも使えるものということになるとSqueakが一番手頃かな。 ちょっとクラスベースの匂いが残ってるけど。 285 名前：デフォルトの名無しさん mailto:sage [04/02/03 09:05] > モノを動かしながら要求分析する時とか。 動かす前にやったらダメかね。 286 名前：デフォルトの名無しさん mailto:sage [04/02/03 09:07] >>285 紙芝居でもいいから動くものが目の前にあったほうが、 お互いに自分の考えを言葉にしやすいわな。 287 名前：デフォルトの名無しさん mailto:sage [04/02/03 14:06] 漏れ思うに、クラスベースのOOの利点ってのは ・強い型付けと組み合わせて、最適化が図れる。 ・クラスに着目して設計が可能なので、クラスの個数＞＞インスタンスの個数であれば 　設計やコード読むのが楽になることがある。 って程度じゃない？でもまあ後者はとても強い利点だと思う。 自由度を制限することによって得られるものもあると思う。主観ばかりでスマソ。 288 名前：デフォルトの名無しさん mailto:sage [04/02/03 14:27] >特にユーザーインターフェースデザインでは効果的。 これなんてプロトタイプ/クラスベース関係ないんじゃない？ デザインの変更にコードをいぢるのかと。 みんなが納得のプロトタイプ利点の実例ってないですか？ 289 名前：デフォルトの名無しさん mailto:sage [04/02/03 15:27] >>288 > これなんてプロトタイプ/クラスベース関係ないんじゃない？ とても関係ある。実際にやってみれば大きな違いがわかると思う。 > デザインの変更にコードをいぢるのかと。 当然いじるでしょ、ボタンの位置を1ピクセル動かすとかでない限り。 どんな情報をどのような時にどのように見せるのか、 これを変えようとしたらコードをいじることになるのは当然でしょ。 その時、目の前にあるGUIが生きたオブジェクトになっていて、 動かしながらそのオブジェクトのコードや変数を直接いじれる。 生きたオブジェクトをプロトタイプからコピってきて、生きたGUIの上に置ける。 そして置いたオブジェクトに変数を定義したりメソッド変えたり、 この直接オブジェクトを作り上げていく感覚はクラスベースではなかなか出てこない。 Smalltalkでさえ、クラスをいじってる限りは間接的な感じがある。 290 名前：デフォルトの名無しさん mailto:sage [04/02/03 16:28] >当然いじるでしょ、ボタンの位置を1ピクセル動かすとかでない限り。 >どんな情報をどのような時にどのように見せるのか、 >これを変えようとしたらコードをいじることになるのは当然でしょ。 別に当然じゃないでしょ。 UIの情報をコードと分けてて後から自由にいじれる クラスベースのシステムだってあるよ。 291 名前：デフォルトの名無しさん mailto:sage [04/02/03 16:55] >>290 > UIの情報をコードと分けてて後から自由にいじれる > クラスベースのシステムだってあるよ。 で、そのUIの情報とやらには何が入るわけ？ GUIってのはViewだけじゃないよ。 MVCで言えば、MVC全部でUIを構成するんだよ。 それを動かして見せようとしたら、M同士の相互関係も必要だよ。 当然、何らかの計算が必要なら、それを実装するんだよ。 それが>>289で言った > どんな情報をどのような時にどのように見せるのか、 ということ。 292 名前：デフォルトの名無しさん mailto:sage [04/02/03 17:40] GUIのデザインっていったらViewだけを指すと思うけど。 MVC全部って言ったらそれはもうシステム全体じゃん。 293 名前：デフォルトの名無しさん mailto:sage [04/02/03 17:56] >>291 が今無能を晒しました。 294 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:06] >>292 > GUIのデザインっていったらViewだけを指すと思うけど。 おいおい、Controllerまで外す香具師は初めてだぞ。 > MVC全部って言ったらそれはもうシステム全体じゃん。 そんなこたーない。 何を表示するか、Modelの吟味無しにマトモなUIデザインができるわけないじゃん。 ミドルティアっぽい部分についてもバックエンドとかパフォーマンスとか頑健性とか エラー処理とかロギングとか、GUI用のプロトタイピングでは無視していいファクター は沢山ある。オモチャみたいなロジックでいいから、動かすことに意味がある。 ちょっと刺がある言い方するけど、UIデザインを甘く見てるんじゃない？ ボタンの位置とかフォントとか色とかだけがUIデザインじゃないよ。 そういうのはあくまでUIデザインの結果にすぎない。 295 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:14] だからそういうのはGUIのデザインじゃなく システムのデザインだろ。 296 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:17] >>294 やめとけ フォーム描きがUIデザインだと思ってる馬鹿には何言っても無駄 しかしコントローラ抜きのUIデザイン藁た 297 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:21] >>295 > システムのデザインだろ。 システムデザインにバックエンドもパフォーマンスも頑健性もエラー処理も不要ならば 君の言う通りだ。 しかし、画面上で関連するModel間の関係だけでシステムデザインができるほど 世の中甘くないんだよ。 298 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:21] ｼﾞｻｸｼﾞｴｰﾝ(･∀･) 299 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:29] >ちょっと刺がある言い方するけど、UIデザインを甘く見てるんじゃない？ >ボタンの位置とかフォントとか色とかだけがUIデザインじゃないよ。 >そういうのはあくまでUIデザインの結果にすぎない。 甘く見るも何もUIデザインなんてかなり地道な作業だとおもうけど。 プログラマというよりほとんどオペレーターというか。 いや毎日そんなんばっかりでなんか愚痴りたくなって。すんまそん。 300 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:39] プロトタイプ的なものをクラスベースで書けないわけじゃないし。 本格的に開発に入って他言語に置き換えるんだったら、 始めからクラスベースの言語で書いた方がイイと思うんだが。 301 名前：300 mailto:sage [04/02/03 18:41] あと、UI のデザイン(アクセシビリティとかも含む)って UI 専門の部署から回ってくるもんじゃないの？ うちの会社じゃそうしてるけど。 302 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:51] 会社の大きさによります。 303 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:53] >>300 プロトタイプを2,3回作って「ハイ、オッケー」ならいいけどね、 実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。 特に、プロトタイプが必要になるような探求的なプロジェクトではね。 そういう時には、プロトタイプベースのほうがその場で手早く手直しして見せられる。 その場で手直しして見せることで、お客さんも自分が何を必要としているのかが だんだん見えてくる。 もちろんクラスベースでもできないことはないけど、プロトタイプベースのハンディさ はなかなか得られない。 あと、プロトタイプで使ったコードを本番に使い回すのはよくないと思うよ。 同じ言語/環境を使うにしても、最初から書き直したほうがいい。 考慮すべきファクターが全く違うから。 304 名前：300 mailto:sage [04/02/03 19:12] > プロトタイプを2,3回作って「ハイ、オッケー」ならいいけどね、 > 実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。 無論、プロジェクトが終わるまで何度も打ち合せはするだろうけど、 なるべく短期間で客の要求を的確に割り出すのが仕事じゃないのか。 ほとんどの場合、ヒアリングで解決することだし。 > あと、プロトタイプで使ったコードを本番に使い回すのはよくないと思うよ。 そりゃまぁ適当に書いたコードを使い回したりするのはマズいだろうけど、 キチンとしたコードなら一向に構わないと思うんだけど。具体例きぼんぬ。 抽象的な話が多すぎて利点が良く分からん。 具体的にどんな仕事でどういう風に使えば、どういう利点があるの？ 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として元の型のままと看倣せるし、 スロットの変更についても、代入と同様の型チェックを実行するだけの話では？ スロットの削除はコピー生成時からあるスロットに対してのみ削除を禁止して、 動的に追加されたスロットは削除してもいいと思うし。

---

---

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

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