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

プロトタイプベース・ ..

263:デフォルトの名無しさん
04/02/01 19:16
>>262
プロトタイプすらないってどういうのを想像しているの？
オブジェクトの拡張はどうやってやるんでしょうか…

264:デフォルトの名無しさん
04/02/01 20:32
丸ごとコピーして変更じゃねーの？

265:デフォルトの名無しさん
04/02/01 20:39
>>261
> 整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、
> クラスとインスタンスの区別があったほうがずっとシンプルにならない？

あんまり差が思いつかない…どんなとこが違いそう？

>>262
> だから，classとinstanceは本質的に違うものであって，それを
> prototype-basedな言語は無理矢理まとめてしまった…とも考えられる．

役割分担するにしても、厳格に分けないほうがやりやすいと思う。
それぞれの object を class とか instance って呼んでもいいけど、
いつでも役割交代させたり、一人二役させたりできる…っていう。

> シンプル，という観点から見れば，prototypeすらないのが一番素直．
> ある程度メモリ効率とかを気にして，classやprototypeが考案されたと．

効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。
使う library 切り替えるときとか、関係する object 全部書き換えるのは大変だし。

それに、全部複製して持たせちゃうような method も、簡単に書けるよね。
どっちを default にするかの違いでしかないと思う。
両方用意するほうが親切だろうけど。

266:263
04/02/01 21:25
>>264 なるほど．

>>265
>効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。
たまにじゃなくて，ほとんどの場合影響して欲しいと思うけど．

267:デフォルトの名無しさん
04/02/01 21:38
そうかなぁ．継承関係はあっても，モノとしては全然関係ないobjectどうしが
影響し合うするのは良くないと思うけどなぁ．

268:デフォルトの名無しさん
04/02/01 21:45
>>267
その、「良くないと思う」レベルが
classベースと、
prototypeベースと、
なんも無しと、
で違うだけだよ。

269:デフォルトの名無しさん
04/02/01 22:02
>>268
影響し合うのはprototype-basedだけじゃない?

270:263
04/02/01 23:20
>>269
クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑

271:デフォルトの名無しさん
04/02/02 09:20
>>270
> クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑

そういう言語もアリだと思うけど。
instance creationした瞬間のclassがそのobjectのclassってことでしょ？

272:デフォルトの名無しさん
04/02/02 17:59
多くのクラスベースな言語では，実行時にクラス変更なんて出来ないし，
出来たとしても，>>271のようになるのが自然だと思う．

273:デフォルトの名無しさん
04/02/03 00:33
>>272
> 出来たとしても，>>271のようになるのが自然だと思う．

そんなこたーない。普通はクラスを変更したらインスタンスも変更される。

274:デフォルトの名無しさん
04/02/03 00:47
普通はって、普通は実行時にクラスを変えられないような。

275:デフォルトの名無しさん
04/02/03 00:52
>>274
普通はって、「出来たとしても」という条件を満たした上での「普通は」でしょ。
文脈からいって。

276:デフォルトの名無しさん
04/02/03 00:56
「普通は」が含まれている文章は、普通、普通でないことを言っている。

277:デフォルトの名無しさん
04/02/03 01:00
すみませんが、どなたかプロトタイプならではって例をﾋﾞｼっと出して利点
を説明してくれませんか？

278:デフォルトの名無しさん
04/02/03 01:06
>>275
それはそうなんだけど、普通はって言うほどサンプルが無い気がして。

メソッドサーチの時にクラスをルックアップするのが普通の実装だから、クラスを変更
したらインスタンスも変更されるでしょうって事かな。

279:デフォルトの名無しさん
04/02/03 01:24
それって「君の普通」でしょ？

280:デフォルトの名無しさん
04/02/03 01:32
そんなに実行時にクラスを変更出来る言語あったっけか。それなら済まない。

281:デフォルトの名無しさん
04/02/03 02:22
>>277
実務での使用だと利点は無い。
なのでみんなクラスベースを使ってる。

282:デフォルトの名無しさん
04/02/03 03:20
>>277
rapid prototyping的に、モノを動かしながら要求分析する時とか。

283:デフォルトの名無しさん
04/02/03 08:35
いやだから、具体的に

284:デフォルトの名無しさん
04/02/03 09:04
>>283
いくつかオブジェクトは出てきているけど
どれとどれが似ていて、どれとどれがどう関連していて
どのオブジェクトがどんな情報を持っているのかはっきりしていない状況では、
クラスを通して間接的にオブジェクトの振舞いを変えていくよりも、
目の前にあるオブジェクトを直接イジれたほうがやりやすい。
特にユーザーインターフェースデザインでは効果的。
クラスベースよりもずっとオブジェクトを直接触っている感覚があるし、
お客さんにもわかりやすい。
そうやって、お互いの理解を深めた上でクラスベースの分析設計に入ればいい。

これ以上は自分で体験してもらわないことには、言葉で伝えるのは難しい。
Smalltalk上にプロトタイプベースな環境を構築したものはいくつかあるから、
どれか試してみるといい。
まあ、今でも使えるものということになるとSqueakが一番手頃かな。
ちょっとクラスベースの匂いが残ってるけど。

285:デフォルトの名無しさん
04/02/03 09:05
> モノを動かしながら要求分析する時とか。
動かす前にやったらダメかね。

286:デフォルトの名無しさん
04/02/03 09:07
>>285
紙芝居でもいいから動くものが目の前にあったほうが、
お互いに自分の考えを言葉にしやすいわな。

287:デフォルトの名無しさん
04/02/03 14:06
漏れ思うに、クラスベースのOOの利点ってのは
・強い型付けと組み合わせて、最適化が図れる。
・クラスに着目して設計が可能なので、クラスの個数＞＞インスタンスの個数であれば
　設計やコード読むのが楽になることがある。
って程度じゃない？でもまあ後者はとても強い利点だと思う。
自由度を制限することによって得られるものもあると思う。主観ばかりでスマソ。

288:デフォルトの名無しさん
04/02/03 14:27
>特にユーザーインターフェースデザインでは効果的。
これなんてプロトタイプ/クラスベース関係ないんじゃない？
デザインの変更にコードをいぢるのかと。

みんなが納得のプロトタイプ利点の実例ってないですか？

289:デフォルトの名無しさん
04/02/03 15:27
>>288
> これなんてプロトタイプ/クラスベース関係ないんじゃない？

とても関係ある。実際にやってみれば大きな違いがわかると思う。

> デザインの変更にコードをいぢるのかと。

当然いじるでしょ、ボタンの位置を1ピクセル動かすとかでない限り。
どんな情報をどのような時にどのように見せるのか、
これを変えようとしたらコードをいじることになるのは当然でしょ。

その時、目の前にあるGUIが生きたオブジェクトになっていて、
動かしながらそのオブジェクトのコードや変数を直接いじれる。
生きたオブジェクトをプロトタイプからコピってきて、生きたGUIの上に置ける。
そして置いたオブジェクトに変数を定義したりメソッド変えたり、
この直接オブジェクトを作り上げていく感覚はクラスベースではなかなか出てこない。
Smalltalkでさえ、クラスをいじってる限りは間接的な感じがある。

290:デフォルトの名無しさん
04/02/03 16:28
>当然いじるでしょ、ボタンの位置を1ピクセル動かすとかでない限り。
>どんな情報をどのような時にどのように見せるのか、
>これを変えようとしたらコードをいじることになるのは当然でしょ。
別に当然じゃないでしょ。
UIの情報をコードと分けてて後から自由にいじれる
クラスベースのシステムだってあるよ。

291:デフォルトの名無しさん
04/02/03 16:55
>>290
> UIの情報をコードと分けてて後から自由にいじれる
> クラスベースのシステムだってあるよ。

で、そのUIの情報とやらには何が入るわけ？

GUIってのはViewだけじゃないよ。
MVCで言えば、MVC全部でUIを構成するんだよ。
それを動かして見せようとしたら、M同士の相互関係も必要だよ。
当然、何らかの計算が必要なら、それを実装するんだよ。
それが>>289で言った
> どんな情報をどのような時にどのように見せるのか、
ということ。

292:デフォルトの名無しさん
04/02/03 17:40
GUIのデザインっていったらViewだけを指すと思うけど。
MVC全部って言ったらそれはもうシステム全体じゃん。

293:デフォルトの名無しさん
04/02/03 17:56
>>291 が今無能を晒しました。

294:デフォルトの名無しさん
04/02/03 18:06
>>292
> GUIのデザインっていったらViewだけを指すと思うけど。

おいおい、Controllerまで外す香具師は初めてだぞ。

> MVC全部って言ったらそれはもうシステム全体じゃん。

そんなこたーない。
何を表示するか、Modelの吟味無しにマトモなUIデザインができるわけないじゃん。
ミドルティアっぽい部分についてもバックエンドとかパフォーマンスとか頑健性とか
エラー処理とかロギングとか、GUI用のプロトタイピングでは無視していいファクター
は沢山ある。オモチャみたいなロジックでいいから、動かすことに意味がある。

ちょっと刺がある言い方するけど、UIデザインを甘く見てるんじゃない？
ボタンの位置とかフォントとか色とかだけがUIデザインじゃないよ。
そういうのはあくまでUIデザインの結果にすぎない。

295:デフォルトの名無しさん
04/02/03 18:14
だからそういうのはGUIのデザインじゃなく
システムのデザインだろ。

296:デフォルトの名無しさん
04/02/03 18:17
>>294
やめとけ
フォーム描きがUIデザインだと思ってる馬鹿には何言っても無駄
しかしコントローラ抜きのUIデザイン藁た

297:デフォルトの名無しさん
04/02/03 18:21
>>295
> システムのデザインだろ。

システムデザインにバックエンドもパフォーマンスも頑健性もエラー処理も不要ならば
君の言う通りだ。
しかし、画面上で関連するModel間の関係だけでシステムデザインができるほど
世の中甘くないんだよ。

298:デフォルトの名無しさん
04/02/03 18:21
ｼﾞｻｸｼﾞｴｰﾝ(･∀･)

299:デフォルトの名無しさん
04/02/03 18:29
>ちょっと刺がある言い方するけど、UIデザインを甘く見てるんじゃない？
>ボタンの位置とかフォントとか色とかだけがUIデザインじゃないよ。
>そういうのはあくまでUIデザインの結果にすぎない。
甘く見るも何もUIデザインなんてかなり地道な作業だとおもうけど。
プログラマというよりほとんどオペレーターというか。
いや毎日そんなんばっかりでなんか愚痴りたくなって。すんまそん。

300:デフォルトの名無しさん
04/02/03 18:39
プロトタイプ的なものをクラスベースで書けないわけじゃないし。
本格的に開発に入って他言語に置き換えるんだったら、
始めからクラスベースの言語で書いた方がイイと思うんだが。

301:300
04/02/03 18:41
あと、UI のデザイン(アクセシビリティとかも含む)って
UI 専門の部署から回ってくるもんじゃないの？
うちの会社じゃそうしてるけど。

302:デフォルトの名無しさん
04/02/03 18:51
会社の大きさによります。

303:デフォルトの名無しさん
04/02/03 18:53
>>300
プロトタイプを2,3回作って「ハイ、オッケー」ならいいけどね、
実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。
特に、プロトタイプが必要になるような探求的なプロジェクトではね。
そういう時には、プロトタイプベースのほうがその場で手早く手直しして見せられる。
その場で手直しして見せることで、お客さんも自分が何を必要としているのかが
だんだん見えてくる。
もちろんクラスベースでもできないことはないけど、プロトタイプベースのハンディさ
はなかなか得られない。

あと、プロトタイプで使ったコードを本番に使い回すのはよくないと思うよ。
同じ言語/環境を使うにしても、最初から書き直したほうがいい。
考慮すべきファクターが全く違うから。

304:300
04/02/03 19:12
> プロトタイプを2,3回作って「ハイ、オッケー」ならいいけどね、
> 実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。
無論、プロジェクトが終わるまで何度も打ち合せはするだろうけど、
なるべく短期間で客の要求を的確に割り出すのが仕事じゃないのか。
ほとんどの場合、ヒアリングで解決することだし。

> あと、プロトタイプで使ったコードを本番に使い回すのはよくないと思うよ。
そりゃまぁ適当に書いたコードを使い回したりするのはマズいだろうけど、
キチンとしたコードなら一向に構わないと思うんだけど。具体例きぼんぬ。

抽象的な話が多すぎて利点が良く分からん。
具体的にどんな仕事でどういう風に使えば、どういう利点があるの？

305:デフォルトの名無しさん
04/02/03 19:15
GUIはオブジェクト指向の考え方が非常に良く当てはまる，
非常に稀な例だからなぁ．

306:デフォルトの名無しさん
04/02/03 19:20
> 実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。
なんかいやな仕事だな。

いやな客にすばやく対応できるとかじゃなく
もっと明るい利点はないですか？

307:デフォルトの名無しさん
04/02/03 19:27
実行時にクラスを変更できる言語は知らないけど，
クラスベースで，オブジェクトへの動的なメンバ追加を許す言語はある(はず)．
メンバの動的変更はプロトタイプベースの特権ではない．

308:1
04/02/03 19:27
具体例，具体例って五月蝿いやつは
まずクラスベースでの具体例だせよ…
クラスあるとこいういう風に綺麗に作れるけど，
プロトタイプベースじゃこうはいかないだろ？
と．

309:デフォルトの名無しさん
04/02/03 19:36
開発方法論のウォーターフォールvsスパイラルで
やってることと同じ内容で言い争ってる？
問題点はもう少し整理しないと。

310:デフォルトの名無しさん
04/02/03 19:39
>>308
プロトタイプベースでもクラスベースでも同じ書き方ができるんなら，
実行効率や型チェックの面で圧倒的にクラスベースの方がいい．
問題は，プロトタイプベースでうまく書けるが，クラスベースではうまく書けない
例がどの程度存在するか，そしてそれは必要なのか，という点．

311:デフォルトの名無しさん
04/02/03 19:43
>>304
> なるべく短期間で客の要求を的確に割り出すのが仕事じゃないのか。

そのためのラピッドプロトタイピング。

> ほとんどの場合、ヒアリングで解決することだし。

十分に枯れたドメインなら言葉だけでいいかもしれんけどね・・・
プロトタイプを動かしながらお客さんの指示に従って変えていくヒアリングもアリだよ。

> そりゃまぁ適当に書いたコードを使い回したりするのはマズいだろうけど、
> キチンとしたコードなら一向に構わないと思うんだけど。具体例きぼんぬ。

プロトタイピングはキチンとしたコードを書くのが目的ではなくて、
お客さんの要求を引き出すために必要十分に動けばいい。
むしろエラー処理やスケーラビリティがキチンとしたコードを書くために
プロトタイプ作成が遅くなるのでは本末転倒になりかねない。
それよりも、目の前にいるお客さんに一秒でも早く動きを見せたほうがいい。
もちろん本番のコードはキチンと書く。当然だよね。

具体例は、俺が実際に経験したプロジェクトを具体的に書くと
狭い業界だからお客さんや俺自身が特定されかねないんで、勘弁。

312:デフォルトの名無しさん
04/02/03 19:43
個人的には，>>267はプロトタイプベースのデメリットだとおもう．

313:デフォルトの名無しさん
04/02/03 19:49
客への対応とかはもうどうでもいいよ…．

314:デフォルトの名無しさん
04/02/03 19:51
結局ここでもLISPが最強ということだな。

315:デフォルトの名無しさん
04/02/03 20:08
Lisp は歴史上の通過点として、プロトタイプベース言語の中でも大きな位置を占めているね。

316:デフォルトの名無しさん
04/02/03 20:15
記述能力については、プロトタイプ言語は（クラスレスであるという）その本質的な特徴よりも、
大抵の実装でオブジェクトがスロット付きであって、メソッをド含むスロットの追加・削除が
動的に可能だということの方が支配的だと思うな。

317:デフォルトの名無しさん
04/02/03 20:22
>>316
良い事言った！
俺もそう思うよ。

318:デフォルトの名無しさん
04/02/03 20:25
>>316
同意．ただ，>>307をどう見るかですな．

319:デフォルトの名無しさん
04/02/03 20:36
クラスが有るか無いかは（この文脈では）それ程大きな問題では無いから、当然 hybrid な
言語があっても良いでしょうね。Ruby みたいな。

320:デフォルトの名無しさん
04/02/03 20:43
結局ここでもRubyが最強ということだな。

321:デフォルトの名無しさん
04/02/03 21:14
文法としてフレームを直接表記できる言語は、なんかやる気でるよね。。
（gcc / g++ でもフィールドを陽に指定する初期化リストなんかが使えるけど）。
ハイブリッドはアリだと思うなあ。フレームに対するメソッドインボケーションは
NewtonScript / Self 式、そうでない、構造体に対しては C++ 式とか。

純粋 prototype ベース（フレーム理論ベース）言語だと、
Complex とか Rect のような小さな構造でオーバーヘッドが大き過ぎ（やる気でない）。

322:デフォルトの名無しさん
04/02/03 23:03
で、なんで Ruby が最強なのか説明してくれ。

323:デフォルトの名無しさん
04/02/03 23:50
>>322
やめろ．荒れる．

324:デフォルトの名無しさん
04/02/04 02:32
クラスの有無は重要じゃないんだよね。クラス指向の人は納得しないだろうけど。

325:デフォルトの名無しさん
04/02/04 03:02
>>324
漏れはクラスがあってもなくても、どっちでもいいけど、
クラス無しでオブジェクトを記述する方法はあったほうがいい派。

326:デフォルトの名無しさん
04/02/04 03:10
クラスがあっちゃ出来ないことって何よ？
結局何も無いだろ？

327:デフォルトの名無しさん
04/02/04 03:20
>>326
だから有る無しじゃないんだってば、おとっつぁん。

328:デフォルトの名無しさん
04/02/04 04:03
>>326
「出来ること/出来ないこと」という論点では、
ほとんどのプログラミング言語はチューリング機械相当ということで
同等だ罠。

329:デフォルトの名無しさん
04/02/04 04:05
オブジェクト指向の神髄はメッセージングにあると思う。で、動的にスロットの参照先を
変更出来れば、より柔軟にメッセージを送受信出来るので嬉しい。

330:デフォルトの名無しさん
04/02/04 10:35
クラスベース言語の言い分としては、設計から実装へと
シームレスに落としこめるというものがある。
その辺り、プロトタイプベース言語やLispなどでは、
プログラマの経験則に多くを負っている。開発手法との
関連付けも弱い。
分析、設計、実装を繰り返すスパイラルな開発においては、
個人的にはプロトタイプベース言語の方が向いているように
思うが、Javaにはそこでもかなりのセオリーや実績がある。

開発手法がプログラミング言語非依存なものであることから
考えて、プロトタイプベース言語が開発のサイクルを回す上で
優れているのなら、実績があってもいいはず。Java派の
人の言う「具体例」とはこういうことだと思う。
まあ言語自体がマイナーだから具体例なんてないけどね（ｗ

俺はEmacsが好きだし、プロトタイプ言語にも活躍の場は
当然あると思うけど、それは優れたプログラマが小人数で
開発するケースにしか使えないと思う。

なお、使い捨てのデモアプリケーションを作るという意味での
プロトタイプ言語はここでは考えていません。

331:デフォルトの名無しさん
04/02/04 12:55
動的かどうか、柔軟かどうかはプロトタイプベースかクラスベースかとは直接関係ないんでしょ?
(プロトタイプベースのほうが柔軟にはしやすいのだろうけど)
じゃあ、あとはどっちを使うかは個々人の流儀の問題で、ただの好き好きに過ぎないって事ですか?

世の中でクラスベースが主流なのは何故?
処理系を実装しやすいのか? 静的な型チェックを厳密にできるからか? 単なる歴史的な経緯か?
世の中をclassifyしたがる人間の性か?

332:デフォルトの名無しさん
04/02/04 13:09
prototype-based の利点が活きるのは、設計が固まる前だと思う。
理想的な water fall で、固まった設計を実装するだけなら、静的な class-based のほうが強そう。
この場合、設計担当の人向きかな、とか。

333:デフォルトの名無しさん
04/02/04 13:26
>>331
世の中でクラスベースが主流なのは何故?
たまたま大手のソフトウェアベンダが採用したっていう
偶然的理由によるところも大きいんじゃないの？

>>332
開発方法論は言語ニュートラルなものとして作られてるけど
その実はかなり関係してるような印象を受けてる。
最近のものは殆どといっていい程、Java、もしくはC(オプソ？)を
想定したものばかりに見えるけど。。。

334:デフォルトの名無しさん
04/02/04 13:31
>>308
プロトタイプベースの利点も分からないのに、クラスベースではこうやる、
なんて出せるわけないだろ。

>>332
>理想的なwaterfallで、固まった設計を実装するだけなら、
>静的なclass-basedのほうが強そう。
クラスベースでwaterfallじゃない開発スタイルも存在すると思うんだけど。
>>>333が言うように、JavaとかCを想定したものが多いけどね。

クラスベースの方が直感的で分かりやすいからじゃないかな。
>>1はお怒りのようだからあんまり言いたくないけど、具体例が出てこないから
プロトタイプベースの言語や、開発スタイルがどういうモノなのかピンと来ないし。

335:333
04/02/04 13:35
途中で送信しちゃった。

prototype-based言語が有用だとJava派の人に対して主張するなら、
具体的な事例はまだないので、その代りに具体的な開発のシナリオを
出す必要があると思うね。開発方法論のセオリーも含めてさ。
言語だけ純粋に見て、その審美性だけで判断するようなことをしても
現実には全然訴えかけるものがないよ。美的観点だけで普及するなら
関数型言語がとっくに広まってるだろうし。

336:デフォルトの名無しさん
04/02/04 14:17
>>335
> prototype-based言語が有用だとJava派の人に対して主張するなら、
> 具体的な事例はまだないので、

をい、>>282さんがあれだけ丁寧に・・・>>332さんも同じ主旨の事を言ってるが、
両方無視かいな。
そもそもJava派って何なんだよ。Java以外のクラスベースはカヤの外かいな。
動的型付クラスベース派はどうすりゃいいんだよ(藁

337:デフォルトの名無しさん
04/02/04 15:00
>>336
具体的な例が(ry…って意見がいくつも出てるんだから、十分な情報じゃないんだろ。

338:デフォルトの名無しさん
04/02/04 16:36
んー。
言語の実践的な有用性については、大手ベンダーがその環境向けの標準開発環境として
採用するかどうかということだけが問題だけなんで、このスレ的にはどうだろうか。。
ってのは333で既出か。

WEB 方面では JavaScript の他に Macromedia Flash の ActionScript でも prototype.__proto__ による
プロトタイプ継承が使われてますね(ECMA Script準拠なんで当然だけど)。

339:デフォルトの名無しさん
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:デフォルトの名無しさん
04/02/04 18:44
要するに、まだ実用例は無いってことね。

342:デフォルトの名無しさん
04/02/04 20:21
Newton Message Pad 自体は商業的に失敗したわけだけど、
一応立派な実用例ではあると思う。

343:デフォルトの名無しさん
04/02/04 21:01
>>330
>それは優れたプログラマが小人数で
>開発するケースにしか使えないと思う。

それで良いんじゃないの?
使い道が分からない人間が無理に使う必要はないでしょ。

>>335
>prototype-based言語が有用だとJava派の人に対して主張するなら、

どちらかというと、Java 派の人にはどこか他所に行って欲しい。
というか過去レス嫁。審美性とか言っちゃって痛杉。

344:デフォルトの名無しさん
04/02/04 21:09
つまり prototype-based を使ってる俺は優れたプログラマなんですよ、と言いたいわけですね？

345:デフォルトの名無しさん
04/02/04 21:18
んにゃ。クラスベース言語に疑問を持たない人が興味を持っても、得る物は少ないから
どっか行けと言いたいだけ。

346:デフォルトの名無しさん
04/02/04 21:33
疑問を持ってるから来てるんだけど、具体例出してくれないんだもん。

347:デフォルトの名無しさん
04/02/04 21:39
クラスのない世界に興味ある椰子がネ申を囲ってマターリするスレでしょ。
クラスマンセーの人に押しつけもせず、クラスがないデメリットも含めて
冷静に語り合うスレでよいと思われ。

348:デフォルトの名無しさん
04/02/04 21:43
>>346
処理系の一つも自分で動かしてみようという気はないのか?
自分の疑問に思ったところを他の言語で実装し直してみれば立派な具体例だろう。
その言語はプロトタイプベースである必要も無い。

349:デフォルトの名無しさん
04/02/04 21:46
>>348
実際にやってみて「別にクラスベースでいいじゃん」と思っただけだが。

350:デフォルトの名無しさん
04/02/04 21:49
>>349
じゃぁクラスベースで良いんじゃない?
迷わず逝けよ。

351:デフォルトの名無しさん
04/02/04 22:03
>>346
どんな疑問ですか？
煽りだけど、まじめに答えてくれればなにかのネタになるかも。

352:デフォルトの名無しさん
04/02/04 22:03
OSchemeが面白そうだからやってみようと思ったら、ダウソできない・・
どっかで落とせませんか？

353:デフォルトの名無しさん
04/02/04 22:07
C#のdelegateって、プロトタイプとうかスロットぽい？

354:デフォルトの名無しさん
04/02/04 22:12
>>352
古いし、動かしてみてないけど。他の Scheme リポジトリも見てみて。

URLﾘﾝｸ(ftp.cs.indiana.edu)

355:352
04/02/04 22:14
自己解決
こっから落とせた
URLﾘﾝｸ(www.cs.indiana.edu)

356:352
04/02/04 22:15
>>354
ありがとう
同じとこだな（ｗ

357:1
04/02/04 22:43
>>353
スロットっていうと名前で参照できるメンバを動的に追加・削除できるようなイメージがあるけど．
マルチキャストデリゲートは機能の追加・削除が行えるけど名前に関しては静的だよね．

358:1
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:デフォルトの名無しさん
04/02/05 01:41
ん。
んで slot の場合には、例えば
if a.hasSlot('asText') then
　write( a.asText() );
else
　write( "unknown object" );
みたいに、「無い」ということも積極的に使うスタイルになります。
DOM の attribute と似てる。

360:デフォルトの名無しさん
04/02/05 13:42
世の中には市場の失敗というのもありうるが、だいたいにおいて市場は良いものの方を選択するから、
結局のところ現状のプロトタイプベースより現状のクラスベースのほうが使いやすいのかも。
(一般的なプログラマにとっては)

一部の神にとっては全てを思い通りに動的にできるプロトタイプベースのほうがいいのかもしれんが。

361:デフォルトの名無しさん
04/02/05 14:27
>>340
> 多分このスレに書き込んでいるほとんどの人はプロトタイプベースOOPL
> を使った開発なんてまともにやったことないでしょう．(私も含めて)

プロトタイプベースは言語よりもむしろ環境として生きるものだと思うなあ。
スクリプトもいいけど、やっぱオブジェクトを記述するメディアとしては
テキストというのは不適合っつーかさ。

>>342
Smalltalk系で言えば、PARTSとかVisualSmalltalkとかあったなあ。
これはクラスベースの環境の上にプロトタイプベース環境を構築したものだから、
ハイブリッドだな。

362:デフォルトの名無しさん
04/02/05 14:44
>>360
> 結局のところ現状のプロトタイプベースより現状のクラスベースのほうが使いやすいのかも。

むしろ、現状を肯定する材料を無意識に探している人も多いんじゃないかと思われ。

クラスベースのほうがいいという理由として最適化を出した人がいるけど、
それで何パーセントパフォーマンスが上がるのか。その何パーセントかが
クリティカルになるシステムが一体どれだけあるのか。

クラスで整理したほうがいいと言いながら、
後になってから1つのクラスを2つのサブクラスに分割する時の手間は
「仕方ない」で済ませてしまう。動的型付ならともかく、静的型付で新しい
サブクラスに応じて型体系をきちんと見直して、インターフェイス型の
定義を洗い直して変数やメソッドの型を適切に修正したりするのは結構
無視できない量の作業のはずなのに。

そういったことを「言語のために負っている手間」と認識せずに
「本質的に仕方ないこと」と看倣している限りは、周りが皆動いてからで
ないと動かないんだろうな。

363:デフォルトの名無しさん
04/02/05 15:05
>362
そういったクラスによるデメリットも、プロトタイプベースの動的さ故に生まれるカオスよりは
マシだということなのかもしれない。
普通のプログラマには枠が有ったほうがいいのかも。あまりに動的だと乗りこなせない。

世の中、Smalltalk, C++, Java とクラスベースで来てるから、
単に流れでクラスベースなだけかもしれないけど。
Kay, Stroustrup, Gosling は何故クラスベースを選択したんだろう。好み?

364:デフォルトの名無しさん
04/02/05 15:11
正直、インターフェース型さえしっかり設計されてれば、
動的だろうが静的だろうが、クラスだろうがプロトタイプだろうが関係ないような。

365:デフォルトの名無しさん
04/02/05 15:59
>>363
> Kay, Stroustrup, Gosling は何故クラスベースを選択したんだろう。好み?

他の2人はともかく、Alan KayはSqueakのMorphでインスタンスベース風な
環境に取り組んでいるのですが・・・

366:デフォルトの名無しさん
04/02/05 16:19
>>362
・クラスベースの方が数倍は速い．(実行速度のことね)
・型付けされていればバグが減る．
ちなみに俺はクラスベースの方がいいとは思ってないが，
クラスベース<プロトタイプベースとも思ってない．

367:デフォルトの名無しさん
04/02/05 16:41
>>366
> ・クラスベースの方が数倍は速い．(実行速度のことね)

これは具体的に何と何の比較？SelfとSmalltalkでこの差が出る？
それともSelfとC++？

どっちかっつーと、クラスベース/プロトタイプベースの比較以上に
プリミティブ型や演算子などの扱いとかのほうが
直接パフォーマンスに効いてくるんじゃないかと思うが。
あと、VMかネイティブコンパイラかのほうが大きいかもしれない。

> ・型付けされていればバグが減る．

プロトタイプベースでも静的型付は可能でしょ。
ただ単に、プロトタイプベースの良さを引き出すためには
多くの言語が動的型付を採用しているというだけの話で。
実際、スロットの動的追加はsubtypingとして元の型のままと看倣せるし、
スロットの変更についても、代入と同様の型チェックを実行するだけの話では？
スロットの削除はコピー生成時からあるスロットに対してのみ削除を禁止して、
動的に追加されたスロットは削除してもいいと思うし。

368:367
04/02/05 16:55
つーか、このスレって

(1) 既存のオブジェクト指向プログラミング言語/環境の比較として、
　　クラスベースとプロトタイプベースのものに分けて比較する。

(2) オブジェクト指向プログラミング言語/環境を設計するための
　　技術要素としてのクラスベース/プロトタイプベースの利点/欠点を
　　比較する。

のうち、どっちなんだろ。

最初のころは「プロトタイプベース・スクリプト言語へのクラス導入ハンターイ」
という意見があったんで(2)もアリだと思っていたのだが、
もし(1)のみが焦点ならば、>>367はとんでもなく的外れになるわけだが。

369:デフォルトの名無しさん
04/02/05 17:20
つか
>実際、スロットの動的追加はsubtypingとして元の型のままと看倣せるし、
動的に追加したら、結局、動的に束縛しなきゃならないわけで、
静的型チェックによる速度向上なんか望めないような。。。

370:デフォルトの名無しさん
04/02/05 17:22
んー漏れは >>1 にあるように;
>オブジェクトを複製または継承によって生成を行う言語，
>プロトタイプベース・オブジェクト指向言語について語りましょうよ．
という趣旨で参加してますた。
だからクラス付き言語との比較の話は「スレ違いだけど、まぁ仕方ないか」って感じで。

371:デフォルトの名無しさん
04/02/05 17:29
漏れはクラスベースかプロトタイプベースかは、言語の優劣のような
ものとは無関係だと思うね。
「オブジェクト指向」を純化させると「プロトタイプベース」になる
というのは理解できるけれども、クラスという仕組みはやはり便利だし、
「プロトタイプベース」であることの利点を述べているつもりでも、
実はその言語が「動的変更をどれだけ許すか？」を語っているだけ
じゃないかと思うことが良くある。
そして「動的vs静的」は古来「柔軟性vs効率」の戦いになって不毛。

372:デフォルトの名無しさん
04/02/05 18:02
JavaScript でプロトタイプベースなOOやってみてるウェブサイトってないですか?

URLﾘﾝｸ(member.nifty.ne.jp)
URLﾘﾝｸ(www.tokumaru.org)
以外で。

JavaScriptなのは他にプロトタイプベース言語知らないから。
ドキュメント豊富なのってこいつくらいだよね。SelfだのNewtonScriptだのは全然見かけないし

373:1
04/02/05 19:16
>>368 >>370
スレ違いではないと思うけど，あまりクラスベースと比較ばっかしてても
>>371の言う通りではないかなぁ．

# というか個人的につまらないだけですが…w

374:デフォルトの名無しさん
04/02/05 19:54
>>371
クラスベースでも動的変更は出来るから，
「クラスベース: 静的」「プロトタイプベース: 動的」とは言えない．
プロトタイプベースとクラスベースの本質的違いはそこではない．

375:デフォルトの名無しさん
04/02/05 22:20
本質とか純化とか優れているとかじゃなくて、もちっと具体的にうれしいのか
説明してくれると嬉しいんだが。RAD だのオブジェクトを触って変更できるって
動的言語なら大抵そうじゃない？オブジェクトを触るっていうけど、別にｸﾗｽﾍﾞｰｽ
だって動的言語なら大抵オブジェクトを操作できますよね？一オブジェクトだけ
メソッド追加/変更とか。

理論的にシンプル（概念が少ないから）だから…というくらいしかわかんないなぁ。
で、とりあえずやってみりゃ分かるだろと思って Self ってのを試そうと
思ったんだが x86 じゃ動かないみたいだし。結局 2ch で聞いてしまうわけだ…。

376:デフォルトの名無しさん
04/02/05 22:36
動的なクラスベースっていうと・・
Smalltalk以外には何があるの?

377:デフォルトの名無しさん
04/02/05 22:51
そんなのいっぱいあるんじゃねーの？スクリプト系とか。Lisp 系も大抵そうだろう。
違いとかじゃなくてクラスベースだとﾏｽﾞｰだけどプロトタイプだとｳﾏｰな点を指摘して
やればいいだけんじゃないのかと思われ。

378:デフォルトの名無しさん
04/02/05 23:10
１オブジェクトだけメソッド追加/変更なんて出来るクラスベース言語ってあるのかな。。
クラス自体を新しく作って、オブジェクトのクラスを変更するんならともかく。

漏れ的にはプロトタイプベースの言語でも大抵なんでもできるんじゃないの、って立場なんで、
逆に 375 の人に「なんでクラス付き言語の方がいいの？」ってのを具体的に聞いてみたい。
広く使われていてライブラリが充実しているので Java がいい、とか、実行速度が速くて
ジェネリックスがやりやすいので C++ がいい、とかさ。

379:デフォルトの名無しさん
04/02/05 23:13
もういっちょ。
プロトタイプベース言語はクラスベース言語の何かについての反省から生まれてきたわけではないし、
誰も「喪前らクラスベース言語はマズイですよ」とも言ってないわけだから、
「クラスベースだとマズー」→「プロトタイプベース言語でウマー」ってのが無きゃならない・あるはずだ、
ということはないと思うんだけど。

380:デフォルトの名無しさん
04/02/05 23:25
>>375
> だって動的言語なら大抵オブジェクトを操作できますよね？一オブジェクトだけ
> メソッド追加/変更とか。

クラスベースできるけどその言語本来が狙っているやり方じゃないような。
純粋にクラスベースで1つのオブジェクトだけメソッドやイ変数を追加しようとしたら、
そのために動的にクラスを生成してそのクラスのインスタンスに化けるという操作
が必要になる。
じゃあその動的に生成したクラスの名前はどうするってこととか、どっかシステム中
に元のクラスを参照している部分があったらそこも変更しなきゃいけないのかとか、
結構面倒なことになる。

で、例えばクラス名は適当に番号か何かを付けて自動的に名前を生成しても、
そんな適当な名前がクラスライブラリに混入することはクラスベースで想定していた
「良いプログラミング」とはかけ離れたものになるんじゃないかな？

そういうクラス絡みの「やり難さ」を取り除くには、クラスでの定義とは独立して
メソッドや変数を追加できる機構が必要になると思われ。
俺的には、そういう機構さえあれば、別にクラスが存在していてもいいと思ってる。

381:デフォルトの名無しさん
04/02/05 23:31
あ、そうなのか！どうやら漏れはとんでもない勘違いをしていたようだ…。
てっきり、クラスベースのなにかを反省して出来たのかと思ったけど、
そうじゃないわけね。うーむ、とりあえず試してみたいがなんか x86 で
動くやつのオススメをキボンヌ。

> １オブジェクトだけメソッド追加/変更なんて出来るクラスベース言語ってあるのかな
例えば CLOS ではできたYO。基本はクラス単位だけどオブジェクト単位でも定義できる。
ついでにメソッドコンビネーションで特定のメソッドの前後に処理を追加するとかもできるのが面白い
と思った。つまり特定のオブジェクトのあるメソッドの前にだけ処理を挿入とかできるｳﾏｰ。

ｳﾏｰな例：
このｵﾌﾞｼﾞｪｸﾄはﾕｰｻﾞｰが触ったやつだから消えるときは知らせよう→削除しますた表示をｵﾌﾞｼﾞｪｸﾄに追加

382:デフォルトの名無しさん
04/02/05 23:37
ま、現実的な市場のニーズはないんだけどな。
漏れのような現場の土方には思考の訓練の道具ってだけだな

383:デフォルトの名無しさん
04/02/05 23:37
>>369
> 動的に追加したら、結局、動的に束縛しなきゃならないわけで、
> 静的型チェックによる速度向上なんか望めないような。。。

いや、他のオブジェクトのメソッドからは、追加したメソッドは叩けないだろ。
静的型チェックしているから。

動的に追加したスロットは、一緒に動的に上書き変更したメソッドの中からしか
叩けないんじゃないかな。
で、それらのスロットを取り除く時には動的チェックするか、あるいは
一緒に動的に追加したスロット群全部をいっぺんに取り除くことにする
って感じでどうよ？
かなり窮屈なプロトタイプベースだが(苦

384:381
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:デフォルトの名無しさん
04/02/05 23:48
>>381
プロトタイプベース言語は、オブジェクト指向言語の一派というよりも、
ミンスキーのフレーム理論の直接の形式化で、
「オブジェクト」ではなく「フレーム」を基本的なデータ構造としています。
URLﾘﾝｸ(www.symlab.sys.i.kyoto-u.ac.jp)
のp38あたりからを参照。

387:デフォルトの名無しさん
04/02/05 23:50
それがオススメですか。んじゃ遊んでみます。
一応年のため聞くけど、処理系は IE とか Mozilla でいいんですよね？

388:デフォルトの名無しさん
04/02/05 23:53
>>384
上の方にリンクが載っているが、Io とか Cecil なら x86 でも動くはず。
Win で Cecil 動かしてる人がいるから参考まで。

URLﾘﾝｸ(www.kmonos.net)

389:デフォルトの名無しさん
04/02/05 23:54
>387ってずいぶん信じやすい香具師なんだな。

390:デフォルトの名無しさん
04/02/05 23:56
ん。すくなくとも Self の論文は Smalltalk を引き合いにクラスベースの不自然さを
淡々と説いているが…？　ただ、結果としてはこのスタンスがまずかった。
オブジェクトベース（aka プロトタイプベース）がまるでクラスベースの対局だという
ような考え方を一般に植え付けてしまったから。

プロトタイプベースって言葉が悪いんだよね。おそらくここで意見を交わし合うべきは
オブジェクトベース（あるいはクラスを意識するならインスタンスベース）のオブジェクト vs
クラスベースのオブジェクトなのであろうかと思うのですが、いかがでしょうか？＞1さん

つまり、オブジェクトが自由に値スロットやメソッドスロットを追加できるとき、どんな
メリット（やデメリット）があるのかとか、スロットへのアクセスにはどんな方法がベターか
とか、そんな話で盛り上がった方がおもしろいと、まあ、そんなふうに思うわけです。

プロトタイプベースとくくってしまうと、オブジェクトの移譲先としてプロトタイプが良いか、
クラスが良いかという結局、好みの問題に終始してしまうので不毛かなと。

391:1
04/02/05 23:56
>>381
ここにあるSelfのcygwin版，動かないんだよねぇ…
URLﾘﾝｸ(www.gliebe.de)

とりあえず，Cecilなんてどうでしょうか？
URLﾘﾝｸ(www.cs.washington.edu)
Interpreterをダウンロードして展開すればすぐに遊べますよ．
ここでも見ながら→URLﾘﾝｸ(www.kmonos.net)
俺はまだほとんど使ってないけど…コレはかなり楽しそう．

392:1
04/02/06 00:03
>>388 マッタリしてたら被ってしまった．ゴメン．
つかレス速っw

>>390
>プロトタイプベースって言葉が悪いんだよね。おそらくここで意見を交わし合うべきは
>オブジェクトベース（あるいはクラスを意識するならインスタンスベース）のオブジェクト vs
>クラスベースのオブジェクトなのであろうかと思うのですが、いかがでしょうか？＞1さん
激しく同意です．
ただ私は無知なのでなかなか積極的に話題振ったりできませんが…

393:デフォルトの名無しさん
04/02/06 00:08
なんというか，クラスベースよりプロトタイプベースの方が純粋にオブジェクト指向
してるとは思えないなぁ．
クラスがない方が自然なの気がするけど，それ以上にプロトタイプのチェインは
不自然な概念だと思う．

394:デフォルトの名無しさん
04/02/06 00:10
開発環境を聞こうと再び 2ch を覗いたら、なんだ、他にもいっぱいあるじゃないか。
>>389 ちょっと前でも JavaScript って話だったじゃないか……正直 age に騙された。
お前らいい香具師らじゃないか。遊んでみるYO!!

で、>>386 のを脳内解釈したところ、
×クラスベースがあってそれをほにゃほにゃしてプロトタイプベースができた
○プロトタイプベースを実現した。で、クラスと比較して～
という理解でいいのかな。

395:デフォルトの名無しさん
04/02/06 00:16
まず，純粋な(クラスもプロトタイプチェインもない)オブジェクトがあって，
でもそれでは，1つ1つのオブジェクトが同じメソッドをバラバラに持ってるのは
効率が悪いから，プロトタイプやらクラスやらが導入されたんじゃないの?

396:デフォルトの名無しさん
04/02/06 00:21
>>390 と >>392 に同意
やっぱ焦点はオブジェクト単位のスロット管理のpros/consだわな。
つまり>>384さんの流れで言うと、CLOSもインスタンスベースとしての機能「も」
持っているわけで。

397:デフォルトの名無しさん
04/02/06 00:23
>>384
何度か出ているけど、CLOS をクラスベースの引き合いに出すのは混乱するから
やめたほうがよいと思いますよ。CLOS のオブジェクトは、スロットこそクラスベース
のオブジェクトと同様にクラスを鋳型にしていますが、メソッドのほうは総称関数という
まったく別の機構で扱われているわけで、誤解を恐れずいうなら、これは抽象データ型
だとかオブジェクト指向とかいった次元を超越した機構なわけですから。

398:380
04/02/06 00:35
>>384
まぎらわしい書き方してすまんです。>>380での「純粋にクラスベースで」とは、
「クラスが管理しているスロット定義情報のみで」という意味のつもりでした。
ので、>>834で挙げてもらったCLOSでの例は「純粋にクラスベースで」には
含めないつもりでした。

で、>>381に挙げてもらった例には大枠で賛成です。
特に、言語レベルでbeforeやafterが使えるのはイイねえ。

399:380
04/02/06 00:43
>>390
> つまり、オブジェクトが自由に値スロットやメソッドスロットを追加できるとき、どんな
> メリット（やデメリット）があるのかとか、スロットへのアクセスにはどんな方法がベターか
> とか、そんな話で盛り上がった方がおもしろいと、まあ、そんなふうに思うわけです。

もうちょい厳密に言うと、それを言語仕様または処理系レベルでサポートすることの
メリット/デメリットということで、どうでしょうか？

そういうオブジェクトを構築できるかどうかということになると、
クロージャを扱える言語/処理系ならば、そういうクラス/オブジェクトを
ユーザの手で作ることができるわけで、それではむしろデザインパターンと
変わらなくなるような気がするので。

400:380
04/02/06 00:44
>>397
> メソッドのほうは総称関数という
> まったく別の機構で扱われているわけで、誤解を恐れずいうなら、これは抽象データ型
> だとかオブジェクト指向とかいった次元を超越した機構なわけですから。

でもマルチメソッド萌え・・・スレ違いスマソ。

401:デフォルトの名無しさん
04/02/06 01:05
>>399
まあ、それは言わずもがなでしょう。オブジェクト指向におけるオブジェクトの
オールマイティ性（と、同時にそれが苦手とすること）ってのは Smalltalk システムが
早々と明らかにしてしまっていますから、ことさらにここでそれを強調する必要もなかろうかと。

そんなことを言い出したら、Lisp 屋さんが出てきて、そんなのオブジェクトなんか使わんでも
俺たちならもっと巧くやれる！ってなことになりかねない(笑)。

402:デフォルトの名無しさん
04/02/06 01:11
>>399
スレの流れ的には大賛成だが、

>クロージャを扱える言語/処理系ならば、そういうクラス/オブジェクトを
>ユーザの手で作ることができるわけで、
こっちの方が超ステキ！（ｷﾗﾝ

次ページ