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

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

152:デフォルトの名無しさん
04/01/25 16:12
>>149
Refactoringは元々Smalltalkerの流儀から来ている。

Smalltalkはオブジェクトを生かしたまま(つまりプログラムの実行中に)
クラス定義を変更したりメソッドを書き変えたりできるから、
まずは何かとりあえず動くオブジェクトを作ってみて、
動かしながら変数をいじったりメソッドを変更していく流儀が前提にあって、
その中から使用頻度が高く機械的にできる変更のパターンをまとめたのが
Refactoring。

別の言い方をすれば、Refactoringは変更し難い言語で変更を容易にするものではなく
元々どうにでも変更しやすい言語で、変更の仕方を分類整理して名前をつけて、
初心者への教育とか、プログラマ間のコミュニケーションを改善するものだと思う。

だから、変更のし難さというのはクラスベースだからというわけではなく、
むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。
つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と
同一視したことによる縛り。

153:デフォルトの名無しさん
04/01/25 16:31
>>152
> だから、変更のし難さというのはクラスベースだからというわけではなく、
> むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。
> つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と
> 同一視したことによる縛り。

うおー、目からウロコだー！ありがとうございます！

>>150-151
議論が噛み合っていない気がするなあ。もうちょっと冷静にやろうよ。

154:1
04/01/25 16:41
>>152
>その中から使用頻度が高く機械的にできる変更のパターンをまとめたのが
>Refactoring。

はぁ？
リファクタリングはパターンじゃないんですけど…
使用頻度とか機械的だとかコミュニケーションとか関係ないんですが．

リファクタリングとは，ソフトウェアの外部的振る舞いを保ったままで，
内部の構造を改善していく作業を指します．
(リファクタリングプログラミングの体質改善テクニック)

155:デフォルトの名無しさん
04/01/25 16:49
>>154
うーん、リファクタリングには定石はあるわけで、それを「パターン」と呼んでも
リファクタリングの趣旨からは離れはしないと思いますよ。
実際、「この長いメソッドは別クラスとして独立させてね」という感じで
パターンを意識したコミュニケーションも行われているし。

まあ、スレ違い気味ではあるが。

156:デフォルトの名無しさん
04/01/25 16:49
パターンってデザインパターンだけを指す言葉ではないよ。本来はもっと意味が広い。
「アナリシスパターン」や「Smalltalk ベストプラクティス・パターン」があるように。
名前を付けて体系化することで、暗黙知を形式知とすることと、
コミュニケーションするときの共通語彙として使えるようにすることが
パターンの目的というか役割。

157:1
04/01/25 16:57
>>155 >>156
言いたいことはわかります．
ただ用語の定義が正確ではないと思ったのでレスしました．

「使用頻度が高く機械的にできる変更のパターン」を
リファクタリングと呼ぶのは間違いです．
リファクタリング・パターンとでも言うべきでしょう．

リファクタリングという作業自体には使用頻度が低いものもあるし，
機械的に行うことが難しいものもあるのです．

158:デフォルトの名無しさん
04/01/25 16:58
>>150
ライブラリ利用時の保証ならクラスブラウザで良いし、実行時の保証ならリフレクションを
使う事になるんじゃないのって事なんだけど。

159:デフォルトの名無しさん
04/01/25 17:19
んでもって、Happy Squeaking!! と SML の該当箇所。

URLﾘﾝｸ(www.ogis-ri.co.jp)
URLﾘﾝｸ(www.sra.co.jp)

Smalltalk でインターフェイスを実装する話。操作の集合としてインターフェイスを
付けるのは良いけど、静的な型システムの代用とはならない。

160:156
04/01/25 17:25
>>157
スレ違いなのでこれで最後。
漏れは
｜使用頻度が高く機械的にできる
を含めた定義には賛成しないよ。

161:155
04/01/25 17:40
>>160
スレ違いなんだけど、私も一つだけ。
私は基本的に「使用頻度が高く機械的にできる」を支持したいなあ。

ソフトウェアの改善という、それまで「一から書き直したほうが早い」と
されてきた手のつけようのない難事業を、
ある程度機械的に処理できるようになったことが、リファクタリングの
第一のご利益だと思うから。

もちろん、リファクタリングの中には、それではすまない部分もあるけど。

162:Java厨
04/01/25 18:04
>>152,>>153
すまぬ。interfaceとclassで、型として何が違うというの？
実装があるかないかの違いだけで、
interfaceは型そのものじゃないか？
Smalltalkがわからんのでリンク先読んでも肝心なところがわからん。
いってみれば、classはvoid型たれ、ということ？
じゃあ、classってなに？

163:デフォルトの名無しさん
04/01/25 18:56
>>159
んでもって、変数宣言時にインターフェイス(の集合)を指定すれば静的型付になる。
この場合の型はクラスとは独立しているからプロトタイプベースでも可能でしょ？

164:152
04/01/25 19:15
厳密に言えば、1氏の言う通り、Refactoringは仕様を変えずに実装を変更する
作業であって、パターンそのものではないです。
しかし、Refactoring作業のカタログ化はFowlerの"Refactoring"のPrefaceに
| The heart of the book, the catalog of refactroings, stretches from
| Chapter 5 through Chapter 12
とあるように、FowlerがRefactoringを普及させるにあたって念頭に置いてい
ることと合致していると思います。

そして、>>149の文脈では
「あるRefactoring作業パターンのリストがあって、
そこから現状の実装に適切な作業パターンを選んで実行することで
漸近的により良い実装に近付けていく。」
という意味合いが強いと思い、あえてカタログ化としての面を前面に出し
>>152のように書きました。

また、「機械的に」や「使用頻度が高い」についても同様で、
Refactoringという作業そのものの定義とは関係ありませんし、
実際に当てはまらないパターンもあります。
しかし、FowlerがRefactoringをカタログ化するにあたって、それぞれ
非常に重要な基準の一つであったのではないかと、
彼の"Refactoring"に掲載されたカタログから推測しました。

165:デフォルトの名無しさん
04/01/25 19:36
>>162
あなたの質問は、いつも私の知りたいポイントを突いているなあ。
ということで、どうかどなたかお教えください。

今までの議論を自分なりに理解すると、
・型、インターフェース…そのオブジェクトにどのような操作が可能か
　定義するもの。
・クラス…そのオブジェクトがどのような継承関係で成り立っているか、
　ライブラリの中でどのような位置にあるかを示すもの。

なのでしょうか？

私もJava厨なので、この二つが別物というのは驚きだし、いまいち
実感が湧かない。

166:1
04/01/25 19:39
>>152
いや，まぁ… なんというか
余計な事に突っこんですまんでした．

Fowlerの本読むとリファクタリングのカタログ的な面が強調され過ぎてて
ちょっと堅苦しいなぁと思ってたんです．
その後Kent BeckのTDD本読んだら「機械的に」や「使用頻度が高い」とか
はあまり関係なくて，リファクタリングという作業，リズムが重要だというか…

167:Java厨
04/01/25 19:50
>>165
>>152をもう一回読んで小便したら気がついたのだが、
classは動的に出来ること(メソッド)がどんどん変わってよい(Javaではできない)、
ということではないかと。
そのときそのときで、なにかのinterfaceの条件にあっていればよい、と。

しかし、それはいびつだなぁ。Aさんが小学生だったのが中学生になり、かつバスケの選手になる、
というのはあるが、全人類が小学生や中学生バスケ選手になることはないと思う。
うーん、やっぱりクラスって何？

168:デフォルトの名無しさん
04/01/25 20:07
今、このスレは自分的には、2chでいちばんの良スレだ。
もちろんアカデミシャンからは稚拙な議論なのだろうけれど、
自分がずっと興味があって、しかし仕事と直接の関わりがなくて手を出せなかった
分野を、何とか自分に理解できるレベルで話してもらえるというのは最高です。

皆さんどうもありがとう。

169:152
04/01/25 20:15
>>166
> その後Kent BeckのTDD本読んだら「機械的に」や「使用頻度が高い」とか
> はあまり関係なくて，リファクタリングという作業，リズムが重要だというか…

そうですね。Kent BeckはXPからもわかるように、開発プロジェクト全体の
手法のほうに着目してますから。

ところでプロトタイプベースでもリファクタリングみたいな作業は重要だと思いますが、
↓こんなのがありますね。
URLﾘﾝｸ(selfguru.sourceforge.net)

個人的にはC++やJavaのような「堅い」言語よりも、プロトタイプベース言語のほうが
Refactoringのカタログを充実させる要請が強いと思うのですが、どうでしょう？
オブジェクトをクラスではなくインスタンス単位でまとめていくために必要になる
「カン所」にうまく名前を付けて、多くのプログラマからそれらを集積して整理する
ことで、プログラマの能力をよりよく発揮させられると思うのですが。

170:デフォルトの名無しさん
04/01/25 20:19
クラスとはオブジェクトを作る"元"で、オブジェクトの構造(実装)やメソッドを定義しておいて、
その類(クラス)のオブジェクトが共通に使うものって事?

で、C++やJavaはクラスを型としても使ってしまっているから混乱するって事?

Smalltalkがクラスを型として使っていないってのは、オブジェクトが何のクラスに属するかは
きっちり決まっていて、クラスからオブジェクトを生成するけど、
オブジェクトをポイントする変数そのものには型が無いって事?

Java のインタフェースも思いっきりクラスの気がするんだけど。実装は持たないし
オブジェクトを作る元にもならないけど、継承もできるし、オブジェクトの分類を示すものには
違いないでしょう?
それでもやっぱり抽象データ型の変形に過ぎないのかな?

171:152
04/01/25 20:32
>>167
> というのはあるが、全人類が小学生や中学生バスケ選手になることはないと思う。

OOの話で例え話はあまり好きじゃないのですが、バスケ選手の話で言えば、

playerという変数の型として、PlayerだのNBAProといったクラスはどうでもいい話で、
むしろmoveableとかthrowableといったインターフェースが重要じゃない？
player.run_to(direction, distance, speed)とかplayer.throw_at(direction, speed)とかが
ちゃんと実行できることが大事なんじゃない？

Playerクラスをplayerの型としてしまうと、車椅子バスケとかに対応しようとした時に
PlayerクラスにFoot leftfoot, rightfoot;なんて変数があったら困ることになるかもよ？
本当はmoveableでthrowableならFootがあろうがなかろうが関係ないんじゃない？

という話です。

172:1
04/01/25 20:36
>>168
なんか最近妙に賑わってるのがなんか怖いw
このスレ立てたのが，プロトタイプベースに関する日本語の資料がほとんど見つからなかった
という理由なんだけど，興味ある人/知ってる人はけっこういるみたいね．
俺もSelfとか使ってみたいんだけど… 初心者が簡単に手をつけられる状況じゃないよなぁ．

173:デフォルトの名無しさん
04/01/25 21:10
>>167ではないけれど
>>171
ならinterfaceのあるJavaは問題ないということですか？

174:Java厨
04/01/25 21:29
>>171
interfaceの適切な粒度とそれ中心で考えるというのは理解するし、普段から心がけている。
話はそれではなく、クラスの定義がどんどん変わると、
世界に散らばったインスタンス達も同様に変わってしまうわけで、
それは普通は変ではないかと。

個々のインスタンスが変身していくのはわかるけど、と。
こう考えると、クラスってなに？と。
クラスベースでクラスにこういうことやるのはおかしくない？と

175:デフォルトの名無しさん
04/01/26 00:35
>>174
クラス定義を動的に変えられることは、仕様の変更を伴うものばかりとは
限りません。メソッド名を変えずに、別のより性能の良いアルゴリズムを
採用したものに差し替えるとか、それこそバグの修正ということもありえます。

大事なのは、システム(アプリ)を停止せずにこれができるということで、
クラスのあるべき立場を危うくすることは目的ではないと思います。Smalltalk
にしても CLOS にしても、できるからといって、クラスの定義がどんどん
変わってゆくような設計は特殊な事情でもなければしないはずです。

176:デフォルトの名無しさん
04/01/26 00:36
171じゃないけど燃えてきたので横槍

>>173
Java の interface は、クラスの定義時に、設計者が
宣言しなければならないところが問題。

例えば、メソッド A と B と C を要求する interface I
があるとしよう。そしてクラス X は A も B も C も定義
している。しかしクラス X が interface I を implements
していなかったら I としては使えないわけだ。つまり、
クラスの作成者があらかじめあらゆる使われ方を考慮
しておかないといけない。でもこれは無理な話なわけで。

ここで動的型付け言語だとそもそもそういう宣言は必要なくて、
実行時に A B C というめそっどがあればよい。また、静的
型付け言語でも interface の後付けができる処理系が
あったはず。そういう機構があるなら、>>171 の言ってる
問題点は解決したと言ってもいいと思うよ。

177:デフォルトの名無しさん
04/01/26 00:44
>>175
>>152の
> だから、変更のし難さというのはクラスベースだからというわけではなく、
> むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。
> つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と
> 同一視したことによる縛り。
とうまく整合できないのですが、
よろしければ補足をいただけませんか？

178:デフォルトの名無しさん
04/01/26 01:01
実行中に変えるということについては、型とかクラス云々ではなく、
実行中にプログラムを変える口を持つかどうかということではないだろうか。

179:デフォルトの名無しさん
04/01/26 01:28
>>176
interface I をインターフェース継承して、Xをメンバに持つ新しいクラス
newXを作ってメソッドA,B,CをXに委譲すれば解決。

180:デフォルトの名無しさん
04/01/26 02:18
みんなクラスとかインターフェースとか、型付けとか好きだねぇ。

181:デフォルトの名無しさん
04/01/26 02:38
>>179
それだと実行前に定義しておかなければならないという問題を全然解決していない。

182:152
04/01/26 04:24
>>177
私は>>175氏ではありませんが、たぶん彼が言いたいのは、
「納入したシステムが実行時に動的に自身のクラスを頻繁に変更するのは
特殊な場合だろう」
ということなのでは？
一方、私の>>152は実行時といっても開発における実行時の話であり、
クラスを変更するのはプログラマです。
というわけで、私としては>>175氏との間に意見の齟齬は無いと思っています。

で、私自身、>>175氏に同意します。
Smalltalkで「実行時に動的に自身のクラスを頻繁に変更する」のも可能では
ありますが、よほど強い要請がなければやりません。
ただ、それが可能であることは重要だと思います。

プロトタイプベースでも同様だと思います。
動的にdelegationを変更したりslotを変更するのは、それ自体が目的ではなく、
表現したい振舞いを簡潔かつ見通し良く記述するための手段に過ぎないわけで
そのためのプロトタイプベースです。
実現したい振舞いを可能にするための動的変更を最小のインパクトに抑えるのは
プロトタイプベースであれクラスベースであれ共通の指針だと思います。
この視点に立った上で、言語処理系自体が動的変更を標準の機能として認めていて
実際に簡潔な記述で動的変更が可能であることは強力な武器だと思っています。

183:厨
04/01/26 12:48
>>182
> 変更のし難さというのは
> 静的型の弊害であり、
> クラスをそのまま型として使うことの弊害
つまり、クラスが静的型だから動的に変えられないよう、と。
で
クラスを動的に変えるのは普通よくないよ。
ということなら、
クラスを静的に変えるときに、静的型うざいよう。
ということになると思うのですが
結局影響を受ける参照箇所は直さなきゃいけないんだから
かわらなくないですか?

184:デフォルトの名無しさん
04/01/26 17:22
>>183
> 結局影響を受ける参照箇所は直さなきゃいけないんだから

もっと具体的に言わないと議論のネタにならないと思われ。

185:デフォルトの名無しさん
04/01/26 18:40
動的に変更できるかどうか、と静的型付けは関係ない、って
ことじゃね？

186:デフォルトの名無しさん
04/01/26 18:51
動的なのが一番だと思う人が多いんだろうけれど、
オブジェクトを動的に委譲でのみリンクしていく
言語だと規模が大きくなると設計とパフォーマンスの
両方ですぐに行き詰まると思う。

187:CLOS
04/01/26 23:00
そこで俺の出番ですよ。クラスベースで型情報つかった最適化も
やるけど、いざというときは Change-Class で変身できるし。
MOP つかえば抽象クラスやインターフェースも作れるよ！

188:デフォルトの名無しさん
04/01/26 23:51
>>183
クラスを動的に変えるのが良くないのは、ある程度仕様が固まってきてからでしょう。
開発初期にオブジェクトの振る舞いを動的に変更出来る事はメリットあると思うな。
私はシステム開発した事が無いので、的外れな事を言ってるかもしれないけど（一応
その周辺部で仕事はしてますが）。

この延長で、全く仕様が固まらない様な仕事、例えば研究者が全く新しい分野のソフト
ウェアを作ろうとしたら? 或は、仕様の変更に柔軟に対応しなくてはいけないシステム
だったら? ソフトウェア自身の速度よりも、ソフトウェアを開発するスピードが重要
だったら? そう言う場合は制約の少ない言語を選びたい人もいるのではないでしょうか?

逆に言えば、経理システムや在庫管理システム向きの言語ではないと思う。
スレの流れに沿ってなくてｽﾏｿ。

189:188
04/01/27 00:07
何か、並のスクリプト言語を擁護してるみたいな文章になってしまいました。
一応、Kansas/Nebraska と Yahoo! Store, 書き捨てのスクリプトを念頭に
置いてます。

あと、病院のシステムを開発するのにも向いてないと思います。

190:デフォルトの名無しさん
04/01/27 00:48
ずばりプロトタイプベースは何の開発に向いてますか？

191:デフォルトの名無しさん
04/01/27 01:42
>>186
それが問題となるのは、あなたが適用すべき言語の選択を間違った時ではないでしょうか。

それは置いておいても、Self は積極的な最適化で結構速いらしいですし、同じ動的言語の
Common Lisp もネイティブコードにコンパイルする事でかなり速いです。

192:デフォルトの名無しさん
04/01/27 17:27
>>191
うーむ、Java にはリフレクションというものがあって、クラス情報の分からない
インスタンスのメソッドやフィールドにアクセスできるようになっている。

しかし、使うのは最低限にしろという原則がある。処理が重いから。
（どのぐらい重いのかは知らないけど）

動的な型付けの言語って、すべての局面でリフレクションをやっているような
ものじゃないのかな？やっぱりどうしても比較すれば重くなるでしょ？

（このリフレクションという言葉が、本来の意味から大きく外れているのを知った
　のは最近…）

193:CLOS
04/01/27 23:18
静的な言語で無理やりなリフレクションするよりは速いかもしれないとは
考えつかないのかな？特に漏れなんてマルチメソッドディスパッチのおかげ
で最悪メソッドコール毎にメソッドの探索が必要になっちゃうけどメソッド
キャッシュやオプショナルな型指定のおかげでそこそこがんがれる。
まぁ、漏れも性能が大事な部分では「オプションで」型指定できたり、
メソッド内では引数の型指定で積極的な最適化が可能だったりと完全に
動的言語ってわけじゃないけどナー。普段は動的で、必要なときに
型を使うわけだ。ウマー。

194:CLOS
04/01/28 00:22
おっと、プロトタイプスレだったな。実は Common Lisp 界でも CLOS みたいな
クラスベースよりプロトタイプベースのほうが逝けてるゼ！とクラスベース vs
プロトタイプベースの争いがあったんで完全にスレ違いってわけでもないのだ。
…と言い訳してみる。

195:デフォルトの名無しさん
04/01/28 00:31
>192
Javaのリフレクションが重いというのは只の伝説です。
今のJVMなら、普通のメソッド呼び出しと殆ど変わりません。EJBなんてリフレクションだらけ。
最低限にしるというのは、コードの解り易さの為。

196:デフォルトの名無しさん
04/01/28 00:44
なんのためのクラス階層なんだか

197:デフォルトの名無しさん
04/01/28 00:53
>>196 どのレスに対して言ってるの？

198:192
04/01/28 01:09
>>193-194
すると、こんな感じ？
Java = 静的な言語だけど、必要に応じて動的にも使える。
CLOS = 動的な言語だけど、必要に応じて静的にも使える。

最近は Java でも、ほとんどのコードはパフォーマンスを気にせずに書いて、
ロジックが完成してからパフォーマンス測定して、ボトルネックになってる
部分だけチューニング、というやり方が増えてきた。

そうすると、CLOS のやり方のほうが便利かも…。

>>195
ああ、そうなんだ！JSP のタグリブとかも、リフレクションの塊なわけで、
「こんなんで良いのかな？」と思ってたんだ。
昔の話だったのね。安心しますた。

199:デフォルトの名無しさん
04/01/28 01:20
>.198
重くないといっても通常のに比べたら数倍はやっぱりかかる。
まあ昔みたいに何十倍もかからなくはなってるが。

200:CLOS
04/01/28 01:29
まぁ、オプショナルな型というのは CLOS というより Lisp の伝統なんだがな。
Lisp マシンの頃からそうだった気がする。基本的にはさっさっと書いて、
プロファイリングして、型を間違ったらヤバそうなところとかボトルネックに
あたりをつけて型指定を入れるスタイルだな。（性能＋型チェックのため）

CLOS 自体は動的な側面が強く、オーバーヘッドを嫌った連中がプロトタイプベース
＋制約ベースの最適化なんてのを考えたりもしたわけだ。最近だと型にかぶれてたり
型推論を装備しちゃた変種まで表れて動的言語とはひとくくりにはできないがな…。

201:デフォルトの名無しさん
04/01/28 04:04
素朴な疑問なんだけど、このスレで Java にはとか Java でもとか言ってる中の人は
Java 以外の言語知らないのかしらん?
Sather ではとか言ってさらさらっとコードでも書いてくれたらｶｺｲｲのに。比較対象
が Java 以外にもあると良いな。

202:デフォルトの名無しさん
04/01/28 04:11
このスレでSatherを出すことにそんな意味があるんですか？
満たされるのはあなたの衒学趣味くらいではないですか？

203:デフォルトの名無しさん
04/01/28 04:52
strong typing な OO 言語の例として出したんだがまずかったかな。他は Eiffel と OCaml
くらいしか知らんし。OCaml でオブジェクト指向している例は見たことが無いし、Eiffel
なら Sather の方が面白そうかなと。後は Strongtalk とか? 色んな言語と比較した方が、
それぞれの関係性も理解出来ると思ったんだが。

204:デフォルトの名無しさん
04/01/28 05:15
プロトタイプのカウンターとして、より多くの人がスレに参加できるJava以外に他の言語が
出てくる必要があるのは、Javaにはない機能や概念に触れた内容のレスである思います。
あなたの真の欲求は、「マイナー言語知識自慢スレ」を立ててそこで満たしてください。
もちろん、このスレで知識を生かしたこのスレの趣旨にあう良レスをしてくれることはみんな歓迎するでしょう。

205:デフォルトの名無しさん
04/01/28 05:35
でもさ、Java な人って議論が設計方面に偏る傾向が無い? 言語の実装とか、言語が備えるべき
機能は何かとか、そういう視点があっても良いと思うんだよね。マイナー言語と片付けるのも
反対はしないけど、それを言ったらプロトタイプベース言語はどうなんだろう。必要な言語に
だけ触れていれば良いの?

206:デフォルトの名無しさん
04/01/28 13:00
私はJava な人の一人です。

私が Java の話しかしないのは、恥ずかしながら「それしか知らない」から。
言語が備えるべき機能についても、Java の機能しか知らないから、他のことが
言えないんす。

このスレに来てるのは、必ずしも Java に満足していなくて、別の可能性を
知りたいからなんす。プロトタイプベースには昔から興味があったし。

設計方面に片寄った話をするのは、実際、そこで困っているから。Java 以外の
可能性に触れることで、それを解決できたら、と思ってます。
あわよくば、Java での仕事に、その言語の考え方を取り入れられたらいいなあ。
デザインパターンやリファクタリングが Smalltalk から取り入れられたように。

まあ、Java な人がみんな、私みたいな厨房というわけではないと思いますが。

207:デフォルトの名無しさん
04/01/28 13:27
Javaしか知らないって奴が出張ってきてもな。
他を自主的に覚えようとしない訳だしな・・。
ここは206の疑問に答えるスレでもないし
とりあえずSmalltalkでも勉強したら？

208:デフォルトの名無しさん
04/01/28 13:39
随分と排他的やね。

209:デフォルトの名無しさん
04/01/28 15:46
ISLISP が最高です。

210:デフォルトの名無しさん
04/01/28 17:56
自分がそのレスに適切と思った言語で書けばよろし。

211:デフォルトの名無しさん
04/01/28 22:21
ところでプロトタイプベース言語を母語として活用している人っているのかな?
今やるなら io が結構良さげな感じがするんだけど、こういう便利な使い方があるぜ
ってのがあったら教えて欲しい。

212:デフォルトの名無しさん
04/01/28 22:34
ここは質問スレではありません

213:デフォルトの名無しさん
04/01/28 23:22
無いから流行ってないんです。

214:デフォルトの名無しさん
04/01/28 23:40
Javaな人とかC++な人ってのは仕事でプログラミングしてる人が多いのだろうから
アカデミックな事にはあまり興味無い実務屋が多いんでしょう

仕事でJavaと付き合ってるのでプライベートでは他の言語とお付き合いしたいという
私みたいなのもいるけど

ちょっと調べたけどJavaScriptってかっこいいなあ。
結構ちゃんとしたプロトタイプベースのOOPLなのね。
私にとってはSmalltalk並にヒット。

215:デフォルトの名無しさん
04/01/28 23:42
>>214
漏れはJavaScriptでクラスを使いたいYo!

216:デフォルトの名無しさん
04/01/29 04:43
色んな嗜好があるもんだな。

217:デフォルトの名無しさん
04/01/29 13:17
ザッと過去ログ読んでみたけど、プロトタイプベースにするメリットが良く分からなかった。

218:デフォルトの名無しさん
04/01/29 13:19
そりゃ実用志向のスレじゃないからね。

219:デフォルトの名無しさん
04/01/29 21:25
Traits
URLﾘﾝｸ(squab.no-ip.com:8080)
> (Traitsを) JavaScript ではまんまクラスと呼んでいる。

JavaScriptでクラスなんて呼ばれるものはあったっけ？
コンストラクタのこと？
確かに、
var a = new String("hoge");
alert(a instanceof String); //true と表示。
という動作を見ると、一見、クラスっぽい。

220:デフォルトの名無しさん
04/01/30 02:44
>>214
今時C++つついてる奴も結構趣味に走ってると思うが。特にtemplate方面。

221:デフォルトの名無しさん
04/01/30 09:28
>>220
趣味だけど実益兼ねているでしょ、アレは。
boost、Loki あたりはウチの会社じゃ普通に使ってるし。

222:デフォルトの名無しさん
04/01/30 09:43
ベンチャーかな？
あんなの使ったら強制デスマーチですが何か？

223:デフォルトの名無しさん
04/01/30 10:09
一応、大手って言われてます。

224:デフォルトの名無しさん
04/01/30 16:06
Lokiなんか使うなとかは低レベルなやつが言ってるだけだろ。
会社じゃ低レベルな奴が足引っ張るみたいだな。
勘弁してほしい。

225:デフォルトの名無しさん
04/01/30 16:29
>>224
> 会社じゃ低レベルな奴が足引っ張るみたいだな。

むしろ自分が使いたい言語の利点をきちんと説得できないのを恥じるべし

226:デフォルトの名無しさん
04/01/30 16:44
>>222
それはいくらなんでもスキル低すぎだろ。

227:デフォルトの名無しさん
04/01/30 19:51
>>225
いや俺会社員じゃないし。
話し聞いてると会社がそういうとこらしいのが嫌だなってこと。

228:デフォルトの名無しさん
04/01/30 19:53
C++の話題はスレ違いです

229:デフォルトの名無しさん
04/01/31 00:41
プロトタイプベース言語で開発するときは、分析モデルの中にクラスは登場するの?
実装モデルには当然クラスは出てこないんだろうけど

基本的にオブジェクトの発見がメインで、ドメインモデルでもクラスは見つけないのかな。

230:デフォルトの名無しさん
04/01/31 00:43
プロトタイプベース言語で大規模プログラミングの例はありますか？

231:デフォルトの名無しさん
04/01/31 01:43
すれ違い覚悟で書くけど、
URLﾘﾝｸ(www.radiumsoftware.com)
こういうのどうよ？
クラスの意味論？とかの観点を語れそうじゃね？

232:デフォルトの名無しさん
04/01/31 04:48
訂正。後半のXenの事ね。
URLﾘﾝｸ(www.radiumsoftware.com)

233:デフォルトの名無しさん
04/01/31 20:22
プロトタイプベースのオブジェクト指向も、ある程度妥協してるよな。
prototypeなんてのを持ち込むくらいなら、素直にclassを認めた方がいいかなと
思ったり。

234:デフォルトの名無しさん
04/01/31 20:38
それをクラスと呼んだ瞬間に、色々余計な概念が持ち込まれるのが嫌だったんでしょう。
クラスなんて本質的に必要なものじゃないし。
Ruby みたいに、クラスのインスタンスだけど後からあれこれ出来ますってのが、厨避け
には良かったのかもしれない。

235:デフォルトの名無しさん
04/01/31 20:49
>>233
プロトタイプはクラスとしても使える、という話じゃなくて？

236:デフォルトの名無しさん
04/01/31 21:37
いや、本来は継承元のメンバも全て自分が持ってるべきでしょ。
それをメモリ効率とかの観点から、prototypeを導入したわけだ。
それなら雛型としてのclassを認めた方が、むしろシンプルかなと思った。

237:デフォルトの名無しさん
04/01/31 21:50
>>236
1,2 行目と 3 行目の繋がりが良く分からないな。「classを認める」というのは具体的に何を
イメージされてるのですか。

238:デフォルトの名無しさん
04/01/31 22:18
>>237
プロトタイプベースでも多くの場合、クラスとインスタンスの関係に近い
オブジェクトをいろいろ用意して使うことになるよね。
それは、暗黙のうちにクラス的なオブジェクトとインスタンス的なオブジェクトを
使い分けてるってことで、なら割り切って、他にも利点のあるクラスベースの方が
いいんじゃないかなぁと思った。
なんというか、プロトタイプは中途半端な気がする。やるならプロトタイプも
なくしてしまえ! と。(w
あー思いつきで適当に書きすぎた。

239:デフォルトの名無しさん
04/02/01 00:17
class なんて特別なものをなくして、 simple にしたんだと思うけどなぁ…
class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。

ところで prototype をなくす利点ってどのへん？
派生先が派生元の変更に影響されなくなることくらいかな…

240:デフォルトの名無しさん
04/02/01 01:09
"特別扱いな部分が少ない言語 == シンプル && 優れている" っていう意識があったけど、
よく使いそうな機能は言語のコアに最初から組み込んでおくべきなんだって考えの人も
居るみたいね。>>232 のリンク先の論文とか。

241:デフォルトの名無しさん
04/02/01 01:14
そういう見方もあるけど、
プログラム=データ構造+アルゴリズムという観点で見ると、
なにか重要な示唆が含まれているような気もする。

242:デフォルトの名無しさん
04/02/01 01:34
>>238
>なら割り切って、他にも利点のあるクラスベース

ここはトレードオフなんだよね。割り切って切り捨てられてしまったものが
結構便利だったりする。対象領域によってはクラス化しない方がシンプルな
場合も多いだろうし。

243:デフォルトの名無しさん
04/02/01 02:59
>>239
> class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。

そんなのclassの実装次第でしょ。

244:デフォルトの名無しさん
04/02/01 03:22
>>243
それならそれを prototype と呼んでも良いわけだ。

よし、この FOO 言語のクラスは従来のクラスにあった制限を一切取っ払った実装にしよう。
ついでに名前も変えて prototype と呼ぼう。これで BAR 言語で出来なかったこんな事や
あんな事も出来るようになるぞ。

245:デフォルトの名無しさん
04/02/01 03:26
型＝インスタンス
ということ自体は全然構わないんだが、

グローバルにしたくないものをグローバルにする必要があったり
メソッドの追加が煩雑だったりするのがかなわん

実用上大問題だと思うんだがどうよ？

246:デフォルトの名無しさん
04/02/01 03:35
>>244
> ついでに名前も変えて prototype と呼ぼう。

そのFOO言語のclassがclassというよりむしろprototypeであることを
ちゃんと理由を付けて説明できるのならね。

247:デフォルトの名無しさん
04/02/01 03:36
>>245
> 型＝インスタンス
> ということ自体は全然構わないんだが、

誰がそんな事を言っているのですか？
このスレでは該当する者はいないようですが・・・

248:デフォルトの名無しさん
04/02/01 03:47
>>246
実装次第でどうとでもなるなら、名前付けにも意味は無いですよねって事なんだけど。

249:デフォルトの名無しさん
04/02/01 03:55
>>248
とりあえず>>94読め。

250:デフォルトの名無しさん
04/02/01 03:58
>>249
それを読むべきなのは >>243 だろうね。クラスの制約の話をしていて、実装次第と
いう答えはどうかと。

251:デフォルトの名無しさん
04/02/01 04:11
>>250
おいおい、>>94に書いてあるのは、インスタンス生成機能をどこに配置するかという問題で、
それはクラスへの制約ではなくインスタンスへの制約なのだが。

クラスが一般のインスタンスと同様の機能を持つクラスベースOOPLだって存在するし、
そのOOPLでのクラスはプロトタイプではなく、あくまでクラスだ。
よってクラスへの制約は実装次第ということで間違ってはいない。

252:デフォルトの名無しさん
04/02/01 04:25
>>251
クラスへの制約なんて話は今まで出てきてないけど、インスタンス生成に関する制約
って事かな。

だいたい、>>94 はインスタンス生成機能だけじゃなく、オブジェクトの分類にも
触れていると思うけど。その上で、モデリングの違いで使い分ければ良いとも読める。

253:デフォルトの名無しさん
04/02/01 05:01
>インスタンス生成機能をどこに配置するかという問題で、
>それはクラスへの制約ではなくインスタンスへの制約なのだが。

ｽﾏｿ。ちゃんと読んでなかった。で、クラスへの制約って何?

254:デフォルトの名無しさん
04/02/01 06:45
>>253
それは>>239に聞かないとわからん罠

255:デフォルトの名無しさん
04/02/01 07:13
>>239 にはクラスへの制約なんて言葉は書いてない。>>251 の空想の中にしかない
概念なんだろうね。自分で参照したレスもちゃんと読んでないみたいだし。
でももう良いよ、終わりにしよう。説明するのも疲れた。

256:94=249
04/02/01 07:24
>>239より引用
> class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。

これがクラスへの制約でなくて何だと言うのだろうか・・・

257:デフォルトの名無しさん
04/02/01 08:00
なんか頭の痛くなる会話してるな

>>255
>でももう良いよ、終わりにしよう。説明するのも疲れた。

説明がちゃんとできてないし、話もお互い通じてないな
おまえら、ろくな定義もされてないあやふやな概念を
一方通行にただ垂れ流してるだけだ
それで余計に疲れるんだろ

258:デフォルトの名無しさん
04/02/01 10:29
で、分析モデルにクラスは出るのか出ないのか?

259:1
04/02/01 11:18
>>132 SeRuby
はRubyでSelfライクを実現，ですが

こちらはJavaScriptライク
URLﾘﾝｸ(mput.dip.jp)

特異メソッド/クラス定義凄い便利だよな．楽しいよな
Rubyが完全にプロトタイプベースだったら…

260:239
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:デフォルトの名無しさん
04/02/01 16:46
>>260
> 充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。

整数とかはどうする？
整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、
クラスとインスタンスの区別があったほうがずっとシンプルにならない？

クラスの有り無しは目的ではなくて手段にすぎないんだから、
「クラスを無くすには」「クラスを導入するには」ってのは
処理系実装以外のシチュエーションではナンセンスだと思う。

262:238
04/02/01 18:41
スレ伸びてるなぁ．びっくり．
>>239
classとobjectを区別しないprototypeでも，実際に使うと自然に
classとinstance的なものを考えるようになる．
だから，classとinstanceは本質的に違うものであって，それを
prototype-basedな言語は無理矢理まとめてしまった…とも考えられる．

> ところで prototype をなくす利点ってどのへん？
> 派生先が派生元の変更に影響されなくなることくらいかな…
これは結構大きい．派生元の影響を受けるから，自然にclass, instanceの
を区別する使い方をしてしまうんだと思う．

シンプル，という観点から見れば，prototypeすらないのが一番素直．
ある程度メモリ効率とかを気にして，classやprototypeが考案されたと．
そんな中で，prototype-basedは，やっぱりちょっと中途半端な気がする．

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デザインの結果にすぎない。

次ページ