- 1 名前：デフォルトの名無しさん [03/12/08 21:30]
- オブジェクトを複製または継承によって生成を行う言語，
プロトタイプベース・オブジェクト指向言語について語りましょうよ．
関連リンク >>2
- 237 名前：デフォルトの名無しさん mailto:sage [04/01/31 21:50]
- >>236
1,2 行目と 3 行目の繋がりが良く分からないな。「classを認める」というのは具体的に何を
イメージされてるのですか。
- 238 名前：デフォルトの名無しさん mailto:sage [04/01/31 22:18]
- >>237
プロトタイプベースでも多くの場合、クラスとインスタンスの関係に近い
オブジェクトをいろいろ用意して使うことになるよね。
それは、暗黙のうちにクラス的なオブジェクトとインスタンス的なオブジェクトを
使い分けてるってことで、なら割り切って、他にも利点のあるクラスベースの方が
いいんじゃないかなぁと思った。
なんというか、プロトタイプは中途半端な気がする。やるならプロトタイプも
なくしてしまえ! と。(w
あー思いつきで適当に書きすぎた。
- 239 名前：デフォルトの名無しさん mailto:sage [04/02/01 00:17]
- class なんて特別なものをなくして、 simple にしたんだと思うけどなぁ…
class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
ところで prototype をなくす利点ってどのへん？
派生先が派生元の変更に影響されなくなることくらいかな…
- 240 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:09]
- "特別扱いな部分が少ない言語 == シンプル && 優れている" っていう意識があったけど、
よく使いそうな機能は言語のコアに最初から組み込んでおくべきなんだって考えの人も
居るみたいね。>>232 のリンク先の論文とか。
- 241 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:14]
- そういう見方もあるけど、
プログラム=データ構造+アルゴリズムという観点で見ると、
なにか重要な示唆が含まれているような気もする。
- 242 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:34]
- >>238
>なら割り切って、他にも利点のあるクラスベース
ここはトレードオフなんだよね。割り切って切り捨てられてしまったものが
結構便利だったりする。対象領域によってはクラス化しない方がシンプルな
場合も多いだろうし。
- 243 名前：デフォルトの名無しさん mailto:sage [04/02/01 02:59]
- >>239
> class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
そんなのclassの実装次第でしょ。
- 244 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:22]
- >>243
それならそれを prototype と呼んでも良いわけだ。
よし、この FOO 言語のクラスは従来のクラスにあった制限を一切取っ払った実装にしよう。
ついでに名前も変えて prototype と呼ぼう。これで BAR 言語で出来なかったこんな事や
あんな事も出来るようになるぞ。
- 245 名前：デフォルトの名無しさん [04/02/01 03:26]
- 型＝インスタンス
ということ自体は全然構わないんだが、
グローバルにしたくないものをグローバルにする必要があったり
メソッドの追加が煩雑だったりするのがかなわん
実用上大問題だと思うんだがどうよ？
- 246 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:35]
- >>244
> ついでに名前も変えて prototype と呼ぼう。
そのFOO言語のclassがclassというよりむしろprototypeであることを
ちゃんと理由を付けて説明できるのならね。
- 247 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:36]
- >>245
> 型＝インスタンス
> ということ自体は全然構わないんだが、
誰がそんな事を言っているのですか？
このスレでは該当する者はいないようですが・・・
- 248 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:47]
- >>246
実装次第でどうとでもなるなら、名前付けにも意味は無いですよねって事なんだけど。
- 249 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:55]
- >>248
とりあえず>>94読め。
- 250 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:58]
- >>249
それを読むべきなのは >>243 だろうね。クラスの制約の話をしていて、実装次第と
いう答えはどうかと。
- 251 名前：デフォルトの名無しさん mailto:sage [04/02/01 04:11]
- >>250
おいおい、>>94に書いてあるのは、インスタンス生成機能をどこに配置するかという問題で、
それはクラスへの制約ではなくインスタンスへの制約なのだが。
クラスが一般のインスタンスと同様の機能を持つクラスベースOOPLだって存在するし、
そのOOPLでのクラスはプロトタイプではなく、あくまでクラスだ。
よってクラスへの制約は実装次第ということで間違ってはいない。
- 252 名前：デフォルトの名無しさん mailto:sage [04/02/01 04:25]
- >>251
クラスへの制約なんて話は今まで出てきてないけど、インスタンス生成に関する制約
って事かな。
だいたい、>>94 はインスタンス生成機能だけじゃなく、オブジェクトの分類にも
触れていると思うけど。その上で、モデリングの違いで使い分ければ良いとも読める。
- 253 名前：デフォルトの名無しさん mailto:sage [04/02/01 05:01]
- >インスタンス生成機能をどこに配置するかという問題で、
>それはクラスへの制約ではなくインスタンスへの制約なのだが。
ｽﾏｿ。ちゃんと読んでなかった。で、クラスへの制約って何?
- 254 名前：デフォルトの名無しさん mailto:sage [04/02/01 06:45]
- >>253
それは>>239に聞かないとわからん罠
- 255 名前：デフォルトの名無しさん mailto:sage [04/02/01 07:13]
- >>239 にはクラスへの制約なんて言葉は書いてない。>>251 の空想の中にしかない
概念なんだろうね。自分で参照したレスもちゃんと読んでないみたいだし。
でももう良いよ、終わりにしよう。説明するのも疲れた。
- 256 名前：94=249 mailto:sage [04/02/01 07:24]
- >>239より引用
> class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
これがクラスへの制約でなくて何だと言うのだろうか・・・
- 257 名前：デフォルトの名無しさん mailto:sage [04/02/01 08:00]
- なんか頭の痛くなる会話してるな
>>255
>でももう良いよ、終わりにしよう。説明するのも疲れた。
説明がちゃんとできてないし、話もお互い通じてないな
おまえら、ろくな定義もされてないあやふやな概念を
一方通行にただ垂れ流してるだけだ
それで余計に疲れるんだろ
- 258 名前：デフォルトの名無しさん mailto:sage [04/02/01 10:29]
- で、分析モデルにクラスは出るのか出ないのか?
- 259 名前：1 mailto:sage [04/02/01 11:18]
- >>132 SeRuby
はRubyでSelfライクを実現，ですが
こちらはJavaScriptライク
mput.dip.jp/?date=20030912
特異メソッド/クラス定義 凄い便利だよな．楽しいよな
Rubyが完全にプロトタイプベースだったら…
- 260 名前：239 mailto:sage [04/02/01 15:41]
- え〜と、説明不足だったかな、ごめん。
class にしかできないことっていうのは、 instance とか subclass の生成あたり。
あとは処理系の柔軟性のなさに応じて、 method や property の追加・削除とか、superclass 変更とか。
class にはできないことのほうは、確かに柔軟な言語にはないかも。
普通の object として複製したり、書き換えたり渡したりってあたりを想定してたけど。
充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。
subclass 作ったり method 書き換えたりはしても、 class じゃない instance は作らないっていう。
で、これを簡潔にしたのが prototype-based OOP だと思う。
もう class なんて概念もいらなくなって、世界には object だけあればいい、っていう。
- 261 名前：デフォルトの名無しさん mailto:sage [04/02/01 16:46]
- >>260
> 充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。
整数とかはどうする？
整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、
クラスとインスタンスの区別があったほうがずっとシンプルにならない？
クラスの有り無しは目的ではなくて手段にすぎないんだから、
「クラスを無くすには」「クラスを導入するには」ってのは
処理系実装以外のシチュエーションではナンセンスだと思う。
- 262 名前：238 mailto:sage [04/02/01 18:41]
- スレ伸びてるなぁ．びっくり．
>>239
classとobjectを区別しないprototypeでも，実際に使うと自然に
classとinstance的なものを考えるようになる．
だから，classとinstanceは本質的に違うものであって，それを
prototype-basedな言語は無理矢理まとめてしまった…とも考えられる．
> ところで prototype をなくす利点ってどのへん？
> 派生先が派生元の変更に影響されなくなることくらいかな…
これは結構大きい．派生元の影響を受けるから，自然にclass, instanceの
を区別する使い方をしてしまうんだと思う．
シンプル，という観点から見れば，prototypeすらないのが一番素直．
ある程度メモリ効率とかを気にして，classやprototypeが考案されたと．
そんな中で，prototype-basedは，やっぱりちょっと中途半端な気がする．
- 263 名前：デフォルトの名無しさん mailto:sage [04/02/01 19:16]
- >>262
プロトタイプすらないってどういうのを想像しているの？
オブジェクトの拡張はどうやってやるんでしょうか…
- 264 名前：デフォルトの名無しさん mailto:sage [04/02/01 20:32]
- 丸ごとコピーして変更じゃねーの？
- 265 名前：デフォルトの名無しさん mailto:sage [04/02/01 20:39]
- >>261
> 整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、
> クラスとインスタンスの区別があったほうがずっとシンプルにならない？
あんまり差が思いつかない…どんなとこが違いそう？
>>262
> だから，classとinstanceは本質的に違うものであって，それを
> prototype-basedな言語は無理矢理まとめてしまった…とも考えられる．
役割分担するにしても、厳格に分けないほうがやりやすいと思う。
それぞれの object を class とか instance って呼んでもいいけど、
いつでも役割交代させたり、一人二役させたりできる…っていう。
> シンプル，という観点から見れば，prototypeすらないのが一番素直．
> ある程度メモリ効率とかを気にして，classやprototypeが考案されたと．
効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。
使う library 切り替えるときとか、関係する object 全部書き換えるのは大変だし。
それに、全部複製して持たせちゃうような method も、簡単に書けるよね。
どっちを default にするかの違いでしかないと思う。
両方用意するほうが親切だろうけど。
- 266 名前：263 mailto:sage [04/02/01 21:25]
- >>264 なるほど．
>>265
>効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。
たまにじゃなくて，ほとんどの場合影響して欲しいと思うけど．
- 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…って意見がいくつも出てるんだから、十分な情報じゃないんだろ。
|
 |
