03/12/08 21:30
オブジェクトを複製または継承によって生成を行う言語，
プロトタイプベース・オブジェクト指向言語について語りましょうよ．
関連リンク >>2
2:デフォルトの名無しさん
03/12/08 21:31
2
3:デフォルトの名無しさん
03/12/08 21:32
プロトタイプベース・オブジェクト指向とは
URLﾘﾝｸ(sumim.no-ip.com:8080)
Google Directory Prototype-based
URLﾘﾝｸ(directory.google.com)
Self
URLﾘﾝｸ(research.sun.com)
Cecil
URLﾘﾝｸ(www.cs.washington.edu)
URLﾘﾝｸ(www.kmonos.net)
Cel
URLﾘﾝｸ(www.redwoodsoft.com)
Io
URLﾘﾝｸ(www.iolanguage.com)
soopy
URLﾘﾝｸ(soopy.sourceforge.jp)
4:デフォルトの名無しさん
03/12/08 21:32
Water
URLﾘﾝｸ(www.waterlanguage.org)
OScheme
URLﾘﾝｸ(koala.ilog.fr)
Agora
URLﾘﾝｸ(prog.vub.ac.be)
Brain
URLﾘﾝｸ(brain.sourceforge.net)
Obliq
URLﾘﾝｸ(www.luca.demon.co.uk)
5:デフォルトの名無しさん
03/12/08 21:32
えへへ
6:デフォルトの名無しさん
03/12/08 21:34
>>2
プロトタイプベースが普及しない理由を述べよ
7:2
03/12/08 21:36
>>6
俺が使ってないから。
8:デフォルトの名無しさん
03/12/08 21:47
OSchemeってのはなんか面白そう
9:デフォルトの名無しさん
03/12/08 22:18
世の中には「やわらかい言語」と「カタイ言語」がある．
やわらかい言語は動的で自由度が高い言語だ．
カタイ言語は静的で制限を設けることによって安全性と効率を得ている．
どっちも一長一短だ．
プロトタイプベースはクラスベースよりやわらかい．
10:デフォルトの名無しさん
03/12/08 22:19
プロトタイプベースはクラスベースより純粋なオブジェクト指向を実現している．
クラスってあまり綺麗な概念じゃないと思うんだけどどうよ？
全てオブジェクトでいいじゃん．
というとクラスもオブジェクトですって答えが返ってくるかもしれないが，
その構造が初心者を混乱させている．
クラスはオブジェクトで，でもオブジェクトはクラスに属している…
11:デフォルトの名無しさん
03/12/08 22:24
クラスのインスタンスをオブジェクトと呼ぶからややこしくなるのだ。
12:デフォルトの名無しさん
03/12/08 22:40
>>11
いや，用語なんかよりもっと根本的問題だと思う．
URLﾘﾝｸ(www.ogis-ri.co.jp)
これが，Smalltalkのクラス構造…
こんなんで，everything is an object, it's beautiful! とか言ってんの．もう見てらんない．
13:デフォルトの名無しさん
03/12/08 22:56
循環構造とトートロジーは違うんですか？
14:デフォルトの名無しさん
03/12/08 23:18
市販 PDA のメイン言語だった NewtonScript が抜けてるじょ。。
あと ECMA Script も。
（こういう商売っ気あるのは面白くないのはわかるけど）。
15:デフォルトの名無しさん
03/12/08 23:21
Singleton みたいに単一インスタンスしか作らないクラスなんかを書いていると、
プロトタイプベースの方が現象を純粋に抽象化してるって感じがする。
クラスの概念はモデル化ではなくって（効率を維持した）アルゴリズム記述の容易さ
のためにあるような気がする。
16:デフォルトの名無しさん
03/12/08 23:21
>>6
ECMA Script (JavaScript) なんか非常に普及していると思うけど。
17:デフォルトの名無しさん
03/12/08 23:28
でもプロトタイプベース言語としてのJavaScriptじゃないっしょ？
18:デフォルトの名無しさん
03/12/08 23:35
>>15
そう．
クラスってイデアみたいなもんだよね．
モデルのモデルについて記述しているわけだ．
まぁイデア論は話としては面白いけど空想なわけで，現実のモデル化にクラスはいらないだろう．
もちろん素直なモデル化を妨げるとしても捨てられない利点があるから使われるんだけど．
俺は言語ヲタなので概念的な美しさを第一に考えちゃう．
C < Pascal
C++ < Java
CommonLisp < Scheme
Smalltalk < Self
と思うわけですよ．この気持わかるでしょ？
19:デフォルトの名無しさん
03/12/09 01:01
>>14 こんなもんでしょうか．
JavaScript デス
ｽﾚﾘﾝｸ(tech板)
ECMAScript
URLﾘﾝｸ(www.ecma-international.org)
NewtonScript
URLﾘﾝｸ(wsmith.best.vwh.net)
URLﾘﾝｸ(www.cc.gatech.edu)
ECMAScriptの実装ってけっこうあるんだね．勉強せねば．
20:デフォルトの名無しさん
03/12/09 01:07
ECMAScriptは独自のオブジェクトを生成できるのか？
JavaScriptをみたところではとてもそんな機能があったようには見えないのだが・・・。
ECMAScriptになってから変わったと？
21:デフォルトの名無しさん
03/12/09 08:22
面白そうなスレ、乙＞１
>>20
ずっと前からあるよ。
ECMAになってから大きい変化は例外かな？
function MyObject(name)
{
this.name = name;
}
MyObject.prototype.hello = function(){ return "hello"; }
o = new MyObject("hoge");
o.hello();
他にも静的スコープ、クロージャはあるし、関数もオブジェクトで
さまざまなプロパティがあったりと、けっこう面白いよ。
22:デフォルトの名無しさん
03/12/09 16:39
>>17
Mozillaの中身はそれっぽい使いかたしてるな。
23:デフォルトの名無しさん
03/12/09 22:23
soopyがシンプルでちょっといい感じだ。
24:soopy
03/12/10 22:43
{
fun main(){do: println "Hello, World!";};
} main();
上の文は、｛ と ｝に囲まれた部分がオブジェクトを表していて、
そのオブジェクトにmainというシンボルを送っています。
オブジェクトにシンボルが送られると、そのオブジェクト内の
同じ名前の要素が返されます。この場合、mainという名前の
関数（実際にはクロージャ）が返ってきます。
そして、返ってきた関数にさらに（）＝ヌル・オブジェクトを
メッセージとして送ることにより、関数が実行されます。
(URLﾘﾝｸ(soopy.sourceforge.jp))
かっこいい!
メッセージモデルが素直に説明できる．
一般的なOOPLのメソッド起動も引数指定もメッセージに統一されてる～
25:デフォルトの名無しさん
03/12/11 01:59
>>18
でもSelfってスロットのモデルがすっきりしないんだよね。
SmalltalkのClass, Metaclass周りのグジャグジャと同じぐらいグジャグジャ。
26:デフォルトの名無しさん
03/12/11 18:28
あまり言及されてないけど、
＞soopyの構文は非常に単純です。大きくわけると次の５種類だけです。
とあるのに、結局は
＞do:
とかの特殊な意味付けの構文（プロパティ？）が色々あるのって、
なんか騙されてる気がするのだが（ｗ
大別してifとloopの２種類ってことらしいけど、
制御構造はまだまだ考慮の余地が残されてる様な。
まそれはおいといて、
メソッド周りの作りは良くまとまってると思った。
27:デフォルトの名無しさん
03/12/11 18:56
>>26
>＞do:
>とかの特殊な意味付けの構文（プロパティ？）が色々あるのって、
>なんか騙されてる気がするのだが（ｗ
書きやすさ、読みやすさに配慮したからでしょう。
あなたなら、どうする？
>制御構造はまだまだ考慮の余地が残されてる様な。
>まそれはおいといて
例外も意外とショボイ。でもパターンマッチがある(w
まあ後は自分で作れということでしょう。
28:デフォルトの名無しさん
03/12/12 02:35
>>23
println "Hello, World!"
で、"Hello, World!" がメッセージというのにはちょっとびっくり。
do: と同様に、従来のALGOL系文法の手続き型言語に馴染んだ人が
逆にびっくりしないような配慮が多くなされている言語のようですね。
個人的には Io に注目しています。SelfのいいとこどりのNewtonScriptの
さらにいいとこどりのような言語で、非同期メッセージ送信までサポート
しています。難点は、Selfと同様、ググったときに欲しい情報になかなか
行き当たらない名前ってところでしょうか(^_^;)。
29:デフォルトの名無しさん
03/12/12 13:43
NewtonScriptで思い出したんですが、プロトタイプベース言語だと
UIレイアウト等のデータ構造記述に混ぜてコードを書けるのが面白い
ですよね。
myArray := [
{ label: "小さいつづら" doIt: func() begin game.over(); end },
{ label: "大きなつづら" doIt: func() begin game.add5points(); end }};
とか。
30:Io
03/12/12 17:57
Io日本語リソースです．ありがたいですなぁ．
今度じっくり読もっと．
+ プログラム言語 Io のはなし
URLﾘﾝｸ(f21.aaacafe.ne.jp)
+ プログラミング言語Io リファレンスマニュアル
URLﾘﾝｸ(user.ecc.u-tokyo.ac.jp)
31:デフォルトの名無しさん
03/12/12 21:41
>>17
そう。しかもECMAScript4とかになると結局クラスが入ってくるしねぇ。
なんだか残念だ。せっかく綺麗な言語なのに。
>>30
どーでもいいがURLとタイトルが逆だぞ。
32:Io
03/12/12 21:50
うわっ かっこわるぅ…
>>31 指摘どうも．
大変失礼しました．貼り直しです．
+ プログラミング言語Io リファレンスマニュアル
URLﾘﾝｸ(f21.aaacafe.ne.jp)
+ プログラム言語 Io のはなし
URLﾘﾝｸ(user.ecc.u-tokyo.ac.jp)
33:デフォルトの名無しさん
03/12/12 22:25
Embedding vs Delegation
多いに語ってくれ
34:デフォルトの名無しさん
03/12/12 23:26
Embeddingって何？
35:デフォルトの名無しさん
03/12/12 23:40
Embedding: あるオブジェクトからメソッドを抽出し，自己に組み込む
Delegation: あるオブジェクトの参照を保持しておき，
自己のメソッド起動をそのオブジェクトのメソッド起動に置き換える
という感じかな？ メソッドで表現すれば．
俺は動的フェチなんでDelegationのが好きだなぁー
36:デフォルトの名無しさん
03/12/13 11:28
>>21
そういう意味での独自のオブジェクトか。
既存のオブジェクトの雛形しか使えないことに変わりないわけだね。
37:デフォルトの名無しさん
03/12/13 12:01
>>36
>既存のオブジェクトの雛形しか使えないことに変わりないわけだね。
プロトタイプベースなんですけど。。
独自のオブジェクトって、たとえばどういうの？
38:デフォルトの名無しさん
03/12/13 12:03
>>35
その方向性なら Forwarding も対象に入るんじゃない？
39:デフォルトの名無しさん
03/12/15 14:27
>>35
文法や表現形式はともかく、
意味論的には行った先での self (this) が誰をさしているか、
といった違いになりますか？
>>36
ちょっと意味がわからないので、何か具体例を挙げて話してくれるとうれしい。
"class" っていうキーワードを使ってないからダメ、だとか。
40:デフォルトの名無しさん
03/12/15 14:42
>>39
> 意味論的には行った先での self (this) が誰をさしているか、
(プロトタイプ指向で一般的な)動的型付の場合にはそれでいいと思う。
静的型付した時にはその限りでないと思う。
41:デフォルトの名無しさん
03/12/17 08:17
cecil やってる人がいるよ。
URLﾘﾝｸ(www.kmonos.net)
42:デフォルトの名無しさん
03/12/23 11:25
URLﾘﾝｸ(www.kmonos.net)
43:デフォルトの名無しさん
03/12/24 00:44
>41-42
>>3
44:41
03/12/24 01:16
>>43
書き込んでから気付いた・・・。
それにしても、スクリプト言語ばっかりだねぇ。
45:デフォルトの名無しさん
03/12/24 13:51
ああっ、こんなスレッドができていた！
プロトタイプベースの言語はJScript（苦笑）しか知らないけれど、大好きだよ。
Javaの仕事をした後、JScriptを書いていると、その素晴らしい自由自在さに
コルセットが外れていくような解放感があるよ。
それと同時に、2chのJavaScriptスレッドの「すぐ目先の実用一点張り」な様子は
とても残念だよ。こんなにきれいで面白い言語なのに。
>>31
激しく同意。クラス導入に反対！
46:デフォルトの名無しさん
03/12/25 16:35
Newtonもってる。だれかおもろいアプリ書いてくり！
47:デフォルトの名無しさん
03/12/30 20:21
age tokuyo
48:デフォルトの名無しさん
04/01/04 09:57
URLﾘﾝｸ(www.ipsj.or.jp)
学校教育用オブジェクト指向言語「ドリトル」。Java 上で動くプロトタイプベース
言語らしい。
49:デフォルトの名無しさん
04/01/04 10:01
URLﾘﾝｸ(kumiki.c.u-tokyo.ac.jp)
ついで。Ruby で実装した Self ライクな環境 SeRuby というのがあるらしい。
50:デフォルトの名無しさん
04/01/04 13:27
>>48
LOGOのOO版みたいなもんですね．
論文は会員じゃなきゃ見れないので…
URLﾘﾝｸ(www.logob.com)
51:デフォルトの名無しさん
04/01/04 14:10
>>50
Squeakみたいだね
似たようなことアラン・ケイが小学生にさせてたのを教育テレビで見たことある
52:デフォルトの名無しさん
04/01/07 01:29
JavaScriptは本物のプロトタイプベース言語とは言えないと思う。
var obj = new Object();
と書いて生成された obj が参照するプロトタイプは、
obj.prototype ではなく、
Object.prototype だ。
だから、オブジェクトのプロトタイプを、生成された個々のオブジェクトごとに
変更することができない。プロトタイプの変更は、同一のコンストラクタから生成された
オブジェクトすべてに影響が及んでしまう。
プロトタイプをオブジェクトごとに、自由に変更できるようにするためには、
オブジェクト一つごとにコンストラクタを一つずつ、用意しなければならない。
まるでクラスベースの型制約に近い不自由さを感じるのだけど。
こんな風に書けたらよかったのに。
var obj;
obj.foo = function(){ alert("ふー！"); };
var obj2;
obj2.prototype = obj;
obj2.foo(); // "ふー！" と表示。
どうしてこうならなかったんだろう？
53:デフォルトの名無しさん
04/01/07 06:35
>>24 のリンク先だけど、soopy では、
>println がオブジェクト、"Hello, World!"がメッセージになります。
println が組み込みオブジェクトだからこういう語順になっている訳だけど、
個人的には Ruby みたいに、"Hello, World!" println のスタイルの方がしっく
りくる。文字列オブジェクトにプリントメッセージを送信て感じ。
soopy 方式は Lisp っぽい(writeline "Hello World!")。
出力先をオブジェクトにして、文字列オブジェクトをメッセージの引数に
している言語もあるね。
Smalltalk は Transcript show: 'HelloWorld!'.
Java も Sysem.out.println("Hello World!")
C++ も cout << "Hellow World!" で Smalltalk と語順的には一緒。
これを、引数渡しのところもメッセージ送信に出来ないかな。ついでに
改行自体もメッセージ式に。
output-port [ "Hello World!" print ]; newline みたいな。
[ "Hello World!" print ] が何を返すべきなのか分からんけど。
54:53
04/01/07 07:40
前のレス、最後のところは無しにして下さい。
println が、オブジェクトなのか、文字列オブジェクトに対するメッセージなのか、
出力先オブジェクトに対するメッセージなのか、言語によって捉え方が色々で
面白いなぁと。
調べてみたら、Smalltalk では「show: 'Hello World!'」で一つのメッセージという
カウントをしてるんですね。
55:デフォルトの名無しさん
04/01/07 08:20
>>52
ECMAScriptではなくてJavaScriptと書いてあるのでJavaScriptの話をすると、
> var obj = new Object();
> と書いて生成された obj が参照するプロトタイプは、
> obj.prototype ではなく、
> Object.prototype
でもなく、
obj.__proto__ だ。
var obj = {}
obj.foo = function(){ print("ふー！"); }
var obj2 = {}
obj2.__proto__ = obj
obj2.foo(); // "ふー！" と表示。
56:デフォルトの名無しさん
04/01/07 08:37
あとちなみに、ECMAScript (3rd) だと、
obj = new Object() の参照するプロトタイプは
obj.prototype ではなく Object.prototype ではなく、 obj.[[prototype]]。
スクリプトからは明示的な読み出しも書き換えもできないので
困る、っちゅーのはその通り。
57:52
04/01/08 01:12
>>55-56
おお、詳しい方ですね！__proto__なんて、昔オライリーのサイ本でチラッと
目にして以来忘れていました。
NN7で試したら、動きました。今でもちゃんと動くんだなあ。
IEで動かないのが残念。
あつかましくて恐縮ですが、質問させてください。
1.obj.[[prototype]]の二重カッコはどういう意味なのでしょうか？
2.ECMAScriptは、どうしてプロトタイプを明示して読み書きできないという、
プロトタイプベースの発達の制限をしているのでしょうか？
どういう設計思想なのでしょう？
私はプロトタイプをもっと自由に使いたいのに。
58:52
04/01/08 01:32
プロトタイプを、例えばどんな風に使いたかったかというと、
画面にたくさんのテキストフィールドがあって、
それのイベントハンドラをいっせいに切り替えるようなこと。
画面のモードによって、いっせいにフィールドの挙動を変えるようなこと。
まず↓のようにセットしておけば、
var common;
var proto1;//たくさんのイベントハンドラが定義してある。
var proto2;//同様に定義してあるが、各イベントハンドラの内容は上と異なる。
for (var form in document.getElementsByTagName("INPUT")){
form.prototype = common;
}
↓のように、ごく簡単に複数のオブジェクトの挙動を変えられる。
common.prototype = proto1;//モード1の動作をセット。
common.prototype = proto2;//モード2の動作に変更。
こうなってたら、とても面白かったと思うのですよ。残念だなあ。
59:55
04/01/08 13:16
>>57
> 1.obj.[[prototype]]の二重カッコはどういう意味なのでしょうか？
「内部プロパティ」のつもり。意味論的にはオブジェクトのプロパティの
一つなんだけど、言語内では触ることのできないシロモノ。
URLﾘﾝｸ(www2u.biglobe.ne.jp)
> 2.ECMAScriptは、どうしてプロトタイプを明示して読み書きできないという、
> プロトタイプベースの発達の制限をしているのでしょうか？
実装の最適化のためだと思うよ。「あとから定義が変更できるクラス」
程度の柔軟性が残ってさえいれば、あとはできるだけ高速化しやすい
仕様を選んだんじゃないかと。知らんけど。
60:52
04/01/09 01:25
>>59
ありがとうございます。実装の最適化ですか…。
私は、クラスベースの言語の挙動に似せるためだと思っていました。
具体的にはJavaですね。
一般のプログラマは、非常に保守的ですから。
Java自体、最初はOAKという、FORTHに似た構文の言語だった時には全く人気が出ず、
Cに似た構文を採用してJavaとなってからやっと使われるようになったといいます。
（しかしJavaは5年ぐらいは、「ポインタ演算のできないC」として扱われた）
LiveScript -> JavaScriptも、Javaとの共通性を（ニセのイメージだとしても）打ち出さ
なければ、普及しなかったのじゃないかなと思うのです。
プロトタイプベースの言語は、そのシンプルな美しさに関わらず、いまや絶滅寸前
ですから。
あまりにも自由自在にすると、クラスベースにある堅牢さから遠ざかり、プログラマから
好まれないのではないか、と設計者が考えたのではないかと私は思っていました。
いずれにせよ、私は現状を残念に思います。今のECMAScriptは、貧者のJavaに過ぎない。
61:デフォルトの名無しさん
04/01/09 02:52
固く考えすぎだと思うんだけどなぁ。
「プロトタイプ指向かくあるべき」という先入観を捨ててから、もう数ヶ月ECMAScriptを使い込んでみて欲しい。
・ECMAScript は JavaScript(Netscape) と JScript(IE) の仕様摺り合わせとして
策定されたもの。そして JScript には __proto__ が実装されていなかった。それだけだ。
ECMAScript1.0が出た頃には、普及も何も、既にWWWのクライアントサイド言語としてシェアをほぼ全制覇していたし。
> プロトタイプベースの言語は、そのシンプルな美しさに関わらず、いまや絶滅寸前ですから。
・絶滅という言葉が使えるほど栄光の時代があったパラダイムではないと思うんだけど。
逆に今ならJavaScript があるし、ActionScript (Flash) がある。プロトタイプチェーンくらいはmetatableで
簡単に実装できるだけの柔軟性をもったLua言語も最近流行し始めた。
もちろん各言語のほとんどのユーザはプロトタイプ指向を用いては
いないだろうけど、それでもSelfしかなかった頃と比べたら、今や
プロトタイプな人の数は雲泥の差だ。
62:52
04/01/10 00:21
>>61
うーん、少々舌足らずだったかも知れません。
ECMAScriptがJavaScriptとJScriptのすり合わせで成立していることは承知している
つもりなのです。
ではなぜ、JScript、JavaScriptがこのような言語になったのでしょうか？
JScriptではプロトタイプはコンストラクタからしかアクセスできず、
JavaScriptでも__proto__は元々隠し機能であり、いつ廃止されるかわからない
状態だった。
それはやはり言語設計者が、プロトタイプを自由に扱わせることに、この言語の普及において
メリットよりデメリットを感じたからだと思うのです。馴染みにくいから。
また、そういうニーズは少ない。ネットを見回すと、JavaScriptでオブジェクト指向を
実現しようとする試みはたくさん見つかりますが、そのほとんどが「いかにしてJavaと
同じ事をするか」に腐心しています。それに対して、JScriptがプロトタイプを公開して
いないことに対する不満を主張するサイトは、私はまだ一度も見たことがありません。
プロトタイプベースの言語が世に広まってきたとは言え、そのほとんどのユーザにその意識が
無いままでは、いつまでも「Javaより貧弱な言語」と見なされるだけで終わってしまうのでは
ないかと思うのです。
63:52
04/01/10 00:22
などと大上段に構えたことを言っておりますが、実は私もつい数ヶ月前までは、プロトタイプ
ベースなんて意識することもありませんでした。
今書いたようなことは、Googleで偶然に
URLﾘﾝｸ(squab.no-ip.com:8080)
このあたりにたどり着いて、中途半端に感化されてしまっただけのことなんです。
すみません。
ただ、今まで オブジェクト指向 ＝ クラスベース としか思っていなかった私には、
まさに目からウロコだったのです。
プロトタイプによる委譲という単純な仕掛けだけで、クラスベースと同等以上の
記述性をもった言語が成立するというのが新鮮だったのですね。
年季の入った人からは稚拙な主張だと思います。
だから、皆さんがプロトタイプベースの言語とどのように付き合っているのか、
お聞かせ願えたらと思います。
例えば、ECMAScriptはこう書けば、このように自由なことができる、とか。
この言語は、このように便利だ、とか。
64:デフォルトの名無しさん
04/01/10 19:53
誰も使ってない
65:デフォルトの名無しさん
04/01/10 21:53
井戸の中に蛙が一匹
66:デフォルトの名無しさん
04/01/10 22:46
効率悪そうだな。
67:デフォルトの名無しさん
04/01/15 19:58
実行効率？なんで？
68:デフォルトの名無しさん
04/01/15 19:59
でも、大規模システムの開発効率は悪そうだな。型機能が不足な分。
69:デフォルトの名無しさん
04/01/15 20:05
いまIoとか絶滅どころかめちゃめちゃアクティブじゃんよ
70:デフォルトの名無しさん
04/01/15 21:14
>>45
JavaScriptは、使われ方からユーザがほとんど厨ユーザだからね。
おまいみたいなヤシばっかだったらいいのに。
71:デフォルトの名無しさん
04/01/15 21:39
あっちのスレは、Web政策版と棲み分けようと努力しているよ。
あとからあとから厨が乱入してくるけど。
72:デフォルトの名無しさん
04/01/15 22:20
他人がスクリプトをどう使うかについて文句を言える筋合いはないが、
実用本位で使うから房っていうのは（もしその意図があるなら）頂けないな。
まあ高邁な学者さんのようなご意見だとは思うけどね。
73:デフォルトの名無しさん
04/01/16 23:06
>>66
Self は JIT で結構速いらしいよ。
プロトタイプ言語のオーバーヘッドは結構大きそうな感じはするけどね。
74:デフォルトの名無しさん
04/01/19 02:27
>>72
そうばかりは言えないよ。あなただって、Java で COBOL みたいなコーディングを
している人がいたら「もうちょっと言語を理解して使ったほうがいいんじゃないの？」
と思うでしょ？
75:デフォルトの名無しさん
04/01/19 02:28
ちょっと JavaScript の話。
別にコンストラクタをたくさん用意しなくても、プロトタイプを自由に変えることは
できる。生成されたオブジェクトが参照するのは、 new されるときにコンストラクタが
保持していたオブジェクトだから。
var Factory = function(){}; //共通のコンストラクタ
//プロトタイプとなるオブジェクト
var a = { foo: function(){ alert("foo A!"); } };
var b = { foo: function(){ alert("foo B!"); } };
//a をプロトタイプとするオブジェクトを生成
Factory.prototype = a;
var a0 = new Factory;
//b をプロトタイプとするオブジェクトを生成
Factory.prototype = b;
var b0 = new Factory;
a0.foo();//「foo A!」と表示
b0.foo();//「foo B!」と表示
76:デフォルトの名無しさん
04/01/19 02:35
>>72
厨なコードを「実用本位」と呼ぶことは、本当に実用になるコードを書く職人さんに失礼。
77:75
04/01/19 02:40
こう書くと、デザパタに慣れた人は、
これが FactoryMethod パターンと State パターンを組み合わせたものに
近い、と感じられないかな。
a と b が State ね。
オブジェクト指向言語には、既存のオブジェクトの機能を利用して新しいオブジェクトを
作る方法が、大きく分けると2つある。「継承」と「委譲」。
クラスベースの言語は、言語レベルで「継承」をサポートし、
プロトタイプベースの言語は、言語レベルで「委譲」をサポートしたものだと
言えると思う。
上と似た動作のコードは Java でも書けるけど、かなり煩雑になる。
78:75
04/01/19 02:56
ということで、蛇足なんだけど、
JavaScriptは、せっかく言語レベルで委譲をサポートしているのだから、委譲を中心に
活用するのが良いと思う。
Java の真似をして、継承という枠組みで使うのは、無理があるし、もったいない。
79:デフォルトの名無しさん
04/01/19 03:18
委譲っていう概念自体が、既存の静的なクラスをベースとした言語を基礎にしてる
気がする。
80:デフォルトの名無しさん
04/01/19 04:12
>>79
なんで？クラスなんて全然関係ないじゃん。
81:79
04/01/19 07:48
>>79
s/言語を基礎に/言語を背景に/
82:デフォルトの名無しさん
04/01/19 23:32
意味不明．
委譲の発祥がクラスベースって言うんだったら
そもそも最初のOOPLがクラスベースだったんだから(ry
83:デフォルトの名無しさん
04/01/20 01:12
クラスベースの多重継承の代替物というイメージが強いからじゃ？
そもそも漏れみたいな厨は、それが委譲のオリジンだと思ってた。
84:デフォルトの名無しさん
04/01/20 03:04
継承と委譲についてだけど、どちらも、
「あるオブジェクトが、自分の実装していない機能があったとき、別のオブジェクトから
それを借りてくる」
という点では変わらない。
で、継承は、オブジェクトを作る金型（クラス）の間で、機能の貸し借りをするの
だけど、
委譲は、実際に生成されたインスタンスの間で、機能の貸し借りが行われる。
型なし言語（だった）JavaScriptが委譲を採用しているのは、まあ当然かも。
85:デフォルトの名無しさん
04/01/20 03:09
>>84
> 型なし言語（だった）JavaScriptが委譲を採用しているのは、まあ当然かも。
型とクラスが混ざってないかい？
86:デフォルトの名無しさん
04/01/20 03:23
あと、無粋なツッコミですまんが、>>83
プロトタイプ・チェインはむしろ単一継承にたとえられることが多いはず。
多重継承は、一回の継承で複数個の親クラスを持つことでしょ？
歴史的経緯については私も知らない。すまん。
87:デフォルトの名無しさん
04/01/20 03:28
>>86
あー、俺は83じゃないが、たぶん83が言いたいのは、
単一継承のOOPLで多重継承的なことをやるために委譲が使われた、
みたいな感じのことだと思われ。
88:デフォルトの名無しさん
04/01/20 03:29
>>85
ん？あなたが言っている型というのは、プリミティブ変数の型のことかい？
私はクラスを、オブジェクトの型として構わないと思うのだけど。
さしさわりがあったら、教えてほしい。
89:デフォルトの名無しさん
04/01/20 03:32
>>87
なるほど、了解。これは私の読み違いだったか。
90:デフォルトの名無しさん
04/01/20 03:35
>>88
例えばJavaにはオブジェクトの型としてインターフェイス型なんてものあるねえ。
ついでに言えば、Smalltalkはいわゆる型なし言語(正確には動的型付言語)
と言われているが、コテコテのクラスベースOOPLだよ。
91:デフォルトの名無しさん
04/01/20 03:47
>>90
ええと、私は「型」というものを、「変数の、ある機能を保証するもの」と
見なしている。例えば、数値型だったら、四則演算が保証される、というように。
同様に、例えばあるインスタンスがコレクション・インターフェースに属していたら、
それはイテレータによる処理が保証されるわけだから、これをオブジェクトの
型とみなして良いと考えていた。
それに対して、プロトタイプベース言語は、実行するまでその操作が可能か、事前には
分からない。型による保証がない。
こういうイメージで、クラス（ないしはインターフェース）を「型」の一種と考えている
んだけど、まずいだろうか？
92:デフォルトの名無しさん
04/01/20 04:03
>>90
Smalltalk については、知らないのでなんとも言えない。
だけど、型なし言語だったら、プロトタイプベースのほうが自然なんではないか
という気がする。オブジェクトの機能の貸し借りに、クラスというものを介在
させずにすむから。
ということで、機会があったら、勉強してみます。
93:デフォルトの名無しさん
04/01/20 04:15
class と interface とが異なるってことだと思う。
class は C++ みたいな言語での、継承の階層図での位置だよね。
対して interface は、 method とかの集合だと思う。
静的で class-based な言語なら一意に対応するだろうけど、
動的な言語だと interface だけ変えるとか、 class だけ変えるとかができそう。
94:デフォルトの名無しさん
04/01/20 04:53
>>92
> だけど、型なし言語だったら、プロトタイプベースのほうが自然なんではないか
> という気がする。オブジェクトの機能の貸し借りに、クラスというものを介在
> させずにすむから。
どうだろうね。
プロトタイプベースではオブジェクトの型紙としての機能を全オブジェクトに持たせるのに対して、
Smalltalkではオブジェクトの分担をはっきりさせ、
Classクラスのオブジェクトにその機能を集中させて専業させることで
その他のオブジェクトを簡素化している、
とも言えるわけで、
全てのオブジェクトにオブジェクト生成機能を持たせるSelfと
オブジェクト生成機能を特定のオブジェクトに専門化させたSmalltalk。
つまり
比較的単質なオブジェクトの集合としてオブジェクト世界を構築するSelfと
色々な種類のオブジェクトの集合としてオブジェクト世界を構築するSmalltalk。
その一方で、
固定的な種別を排除した雑多なオブジェクト世界を構築するSelfと
クラスという明確な種別による整然としたオブジェクト世界を構築するSmalltalk。
結局はコインの表裏ってとこだよ。
どっちが自然というよりは、モデリングの視点が違っているだけの話だと思う。
あとは趣味の問題。
95:デフォルトの名無しさん
04/01/20 08:38
オブジェクト生成機能って、new とか init, alloc, clone みたいなの?
96:デフォルトの名無しさん
04/01/20 09:00
>>95
まあそんなもの。
属性名とスロットインデックスの対応とかメソッド辞書等の、
オブジェクトの構造や機能に関する情報と、
それを使ってオブジェクトを生成する操作。
97:デフォルトの名無しさん
04/01/20 17:51
>>94-96
なるほどねえ。
プロトタイプベースについて論じるためには、実はクラスベースについても
広くきちんとした知識をもっていなければならないのだなあ。
勉強になりました。
98:デフォルトの名無しさん
04/01/20 17:57
ということで、ややスレ違いで恐縮なんだけど、
>>93のように、Smalltalk って、インスタンスの属するクラスをを動的に変更
できるの？まさか、キャストのことじゃないよね？
インスタンスが生成されたあとでも、その属するクラスを動的に変更できると
したら、プロトタイプベースと同等の自由度だよね？にわかに信じがたい。
もし本当なら、Javaでは信じられない世界だ。
99:デフォルトの名無しさん
04/01/20 21:42
>>97
ここら辺が参考になるかと。
URLﾘﾝｸ(www.shiro.dreamhost.com)
URLﾘﾝｸ(homepage.mac.com)
>>98
CLOS ではオブジェクトが属するクラスを後から変えられるみたい。
Smalltalk では become: というメソッドがあったらしい。
URLﾘﾝｸ(www.sra.co.jp)
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
URLﾘﾝｸ(homepage.mac.com)
>その属するクラスを動的に変更できると
>したら、プロトタイプベースと同等の自由度だよね？
サブクラシングせずに、オブジェクト毎にメソッドを追加／上書き出来ないと
同等じゃないと思う（個人的には）。
私はプログラマでも言語実装者でもないので、全部伝聞でｽﾏｿ。
100:1
04/01/20 23:39
100.get!
101:1
04/01/20 23:45
>その属するクラスを動的に変更できると
>したら、プロトタイプベースと同等の自由度だよね？
そこまでしてクラスに拘る理由があるのか疑問．
そうやってどんどんクラスベースに柔軟性を持たせると，
結局プロトタイプベースと同じものになるだろう．
そうなったらクラスという概念が無い方がシンプルでわかりやすい．
自由度と危険性を手に入れたいならクラスという概念はいらないはず．
102:デフォルトの名無しさん
04/01/21 00:03
オブジェクト to オブジェクトのトランスレートなんて頻繁に起こる物じゃないから、
基盤をクラスに置く事は何の不思議もないと思うけど。
103:デフォルトの名無しさん
04/01/21 01:51
>>102
そうかな？
あるオブジェクトのインスタンスがあって、モードによってその動作を
ガラッと変えたい、なんて場合には、ぜひとも既存のインスタンスの
属すクラスを、別のものに変えたいと思うけどなあ。
GUI の設計とかしていると、よくそういうことない？
というか、Java でよく使う Stateパターンって、動的にクラスの
変更のできない言語で、委譲先を変えることによって機能をそっくり
取り替えてしまおう、というものでしょ？
（まあ、メソッドの内容は変えられても、シグナチャは変えられないんだけど）
ということで、今はそんなにクラスの変換は行われていなくても、もし言語が
それをサポートしているなら、需要はいくらでもあると思う。
104:デフォルトの名無しさん
04/01/21 01:53
>>103
自己訂正。
State パターンで変えられないのはシグナチャ、という言い方は不適切だな。
メソッド自体を新設したり、廃止したりということはできない、とすべきだった。
105:デフォルトの名無しさん
04/01/21 02:22
>>98
> ということで、ややスレ違いで恐縮なんだけど、
> >>93のように、Smalltalk って、インスタンスの属するクラスをを動的に変更
> できるの？まさか、キャストのことじゃないよね？
キャストじゃないよ。そもそもSmalltalkは動的型付だからキャストは存在しない。
> インスタンスが生成されたあとでも、その属するクラスを動的に変更できると
> したら、プロトタイプベースと同等の自由度だよね？にわかに信じがたい。
> もし本当なら、Javaでは信じられない世界だ。
とりあえず簡単なやり方としては、
1. 自分相当のオブジェクトを違うクラス(仮にAnotherMyClassと呼ぶ)で生成する。
newSelf ← AnotherMyClass from: self.
2. 自分をnewSelfにする。
self become: newSelf.
これで、今までの自分とはサヨナラ、これからの私はAnotherMyClassのオブジェクトです、
となる。
ちなみに>>99さん、become:はまだ生きてますよ。
というか、Smalltalkはこれがないと根本的に動かない。
106:デフォルトの名無しさん
04/01/21 02:51
>>105
素晴らしい！Smalltalk ってそんなに自由なのか！
クラスベースにも、こういう可能性があったのですね！
こんなJava厨の質問に答えてもらって申し訳ない。
ありがとう、>>105の中の人！
107:Java厨
04/01/21 04:22
オブジェクトの各変数（フィールド）はどうなるの？
108:デフォルトの名無しさん
04/01/21 11:16
>>105
#become: を使っているだけに #become: の挙動みたいな説明ですね(笑)。
完璧に化ければそれはもはや本人と見なしてよいか…という問題をはらんでいます。
私は、もともと self に束縛されていたオブジェクト（ここで「被害者」、
今は newSelf に束縛されている）のアイデンティティを擁護する
立場(^_^;)なので、被害者のクラスについてはこの処理を経たあとも
それまでとなんら変わらない事実を踏まえて、Smalltalk のインスタンスに
そのクラスを鞍替えすることは特殊な状況を例外として「できない」
と答えるのは正解かな、と。
特殊な状況とは、そのクラス(仮に Hoge )のインスタンスがひとつしかなく、
そのインスタンスが鞍替えする先のクラス(同じく Hage )のインスタンスが
なく、さらに Hoge 、Hage がサブクラスを持たない場合です。このように
状況を限定すれば、 Hoge become: Hage を使って注目するインスタンスの
「クラスは変わった」と判断してもよいように思います。
| hoge hogeClass hogeO |
hoge _ Hoge new.
hogeClass _ hoge class printString.
hoge o: $o.
hogeO _ hoge o.
Hoge become: Hage.
^ {hogeClass. hogeO. hoge class printString. hoge a}
=> #('Hoge' $o 'Hage' $o)
このようにインスタンスとそのクラスとの委譲関係は自由にはできませんが、
クラスをしてそのスーパークラスとの委譲関係は比較的自由に乗り換えられる
ことは話の流れ的には強調してもよいのかな…、とも。
109:105
04/01/21 12:22
>>108
> 完璧に化ければそれはもはや本人と見なしてよいか…という問題をはらんでいます。
ようするにアイデンティティをどう捉えるのかという問題ですね。
あなたはSmalltalkerのようなのでSmalltalkで答えると、
anOrderedCollection ← OrderedCollection new: 0.
anOrderedCollection addAll: #(1 2 3 4 5)
ここで、2行目の実行前と実行後で、anOrderedCollectionが同じオブジェクトで
あると看倣す人であれば、become:によってクラスを変更できると答えるべきだと
思いますが、いかがでしょう？
> 状況を限定すれば、 Hoge become: Hage を使って注目するインスタンスの
> 「クラスは変わった」と判断してもよいように思います。
クラスオブジェクトにbecome:を使うと色々と後片付けが面倒なんで・・・
不可能とは言いませんが、それこそ特定のクラスに対して、よほど注意しながら
でないと使うべきではない手ではないかと。
＃じゃ非クラスインスタンスに対してはbecome:を気軽に乱発していいかというと(ry
110:105
04/01/21 12:47
成り行きとはいえ、スレ違いのSmalltalkネタを書きすぎました。
スレ汚しスマソ。
111:デフォルトの名無しさん
04/01/21 21:28
>>110
いや、ちっとも迷惑じゃないです。
ということで、>>107 について簡単でよいから教えていただけませんか？
私も知りたい。
112:デフォルトの名無しさん
04/01/21 22:53
CLOS についても聞きたいっす。名前だけは見かけるんだけど。
実際どうなんでしょ？柔軟性という点ではプロトタイプベースとタメを
はれるんでしょうか？
113:デフォルトの名無しさん
04/01/22 01:56
>>103
クラスの付け替えは、閉じた環境の中で実装しながら設計するという Smalltalk や
Lisp 特有のニーズだと思っていたけど、そこまで積極的に使いたいなら >>101 の
言うように最初からプロトタイプベースの言語を使用した方が良いのでは?
クラスは型システムみたいにある種の保証を持たせたり、最適化のポイントとして
使われる場合もあるから、ほいほい変えられるものじゃないと思うけど。
実際初期の Squeak では、オーバーヘッドを考えて become: の使用をなるべく
減らす様な実装にしていたらしいし（処理系依存だけど）。
114:105
04/01/22 14:34
>>111
簡単に言うと、今まで自分を指していた参照がbecome:の引数のオブジェクトを
指すようになるだけなので、今までの自分の各変数はどうにでもなります。
実際の実装はともかくとして、言ってみればシステム中の全参照の中から
自分を指している変数をbecome:の引数のオブジェクトに指し替えてやるだけです。
なので、元のオブジェクトのインスタンス変数から新しいクラスのインスタンスに
どう情報を持ってきてコピーするのかは、>>105の例で言えば、from:の実装次第。
変数名や宣言の順番(スロット位置)や変数の数など、同じでも異っててもいいです。
というか、そのオブジェクトに関係している他のオブジェクトが混乱しなければ
つまり同じようなメッセージに反応できて、同じような意味の振舞いを示せば
あとはどうでもいいのです。(動的型付の強みです)
例えば元のオブジェクトにはstart, endの2つの変数があって、新しいオブジェクト
にはlength, offsetの2つの変数があったとします。たぶんfrom:の実装は
from: anOriginalObject
| aNewObject |
aNewObject ← self new.
aNewObject setLength: anOriginalObject end - anOriginalObject start.
aNewObject setOffset: anOriginalObject start.
↑aNewObject
みたいな感じでしょう。
これで、NewObject from: anOriginalObjectとすると、lengthおよびoffsetが
適切に設定されたNewObjectのインスタンスが生成されます。
115:105
04/01/22 14:37
なお、>>109で出した例はどういう意味かというと、
SmalltalkではOrderedCollectionという可変長配列みたいなクラスがあります。
これはどうやってサイズを可変にしているのかというと、
自分よりちょっと大きなサイズのOrderedCollectionのインスタンスを作って、
中身に自分の中身をザクっとコピーしておいて、
そいつにbecome:するのです。
つまり、厳密に言えばそのオブジェクト自体が可変長なのではなくて、
別のサイズのコピーにbecome:することで「実質的に」可変長になっています。
(多少のサイズの変動はbecome:することなしにfirstIndex, lastIndexで調整しますが)
ここで、新しいOrderedCollectionのインスタンスを作るとき、
新しい大きさに適した別のクラスのインスタンスに変更していくことも可能です。
(現在の実装では、ずっと同じクラスのインスタンスのままです。)
>>109で、OrderedCollectionのサイズ変更前と後とで同じオブジェクトと看倣すの
であればクラスも動的に変更できると看倣すべき、と言ったのは、この意味です。
じゃ、これでこの流れのSmalltalkネタは最後にしますです。
また面白そうなネタがあったら口を挟ませてもらいます。
116:デフォルトの名無しさん
04/01/22 16:16
とある知り合いの言うことには、
「クラスベースのオブジェクト指向言語は
リファレンスマニュアルが書きやすいからいいんだよ」
とても納得した。
117:デフォルトの名無しさん
04/01/23 03:49
>>114-115
予備知識がなくて難しいですが、ある程度分かった気がします。
become: というのは、他のインスタンスを自分のアドレスにコピーすることなのですね？
それなら、オーバーヘッドが大きいのも分かります。
from: の実装次第で、どのようなクラスに変えることができるのも分かりました。
>>108-109 については、正直「なんとなく分かった？」程度ですが、自分としては
一応満足です。さすがにこれ以上はスレ違いでしょうし。
丁寧にご説明いただき、大変ありがとうございました。
118:デフォルトの名無しさん
04/01/24 00:10
プロトタイプベースに対するクラスベースの優位性ってなんですかね？
その一つは型チェックだと思うんだけど、Smalltalkのようなインタプリタだと
その利点もなくなるし、結局なにがいいのかな？
119:デフォルトの名無しさん
04/01/24 01:56
>>118
Smalltalk言語処理系は基本的にコンパイラベースです。Smalltalk環境内であまりに
自在にコードを評価できるので勘違いされがちですが…。いちおう、念のため。
クラスベースのアドバンテージですが、結局は型チェックの例と同様に、ある種の
制約を課すことによる安心感、安定さ、安全性に尽きると思います。
クラスベースとプロトタイプベースをコインの表裏、テーゼとアンチテーゼのように
例える向きもありますが、それよりむしろ、クラスベースはプロトタイプベースが実現できる
システム形態のひとつだと考えるほうがいろいろなことをうまく説明できます。
Smalltalk 処理系を Self で比較的すなおに実装できるのに対して、逆はそうでは
ないことなどは、その良い例でしょう。
120:デフォルトの名無しさん
04/01/24 02:53
-- プロトタイプベース言語、何それ?
ふーん、クラス無いの。静的型チェックも出来ないんだ。
オーバーヘッドも大きそうだし、そんなにころころ挙動が
変わったらドキュメント作る時どうするの。そんなふわふわ
した言語でコーディングなんて出来ないよ。学者さんの研究
じゃないからね。こっちは仕事で納めるコードを書いてるんだ。
って言われない事。
121:デフォルトの名無しさん
04/01/24 02:58
>>119
> Smalltalk 処理系を Self で比較的すなおに実装できるのに対して、逆はそうでは
> ないことなどは、その良い例でしょう。
んなわきゃない(苦笑
122:デフォルトの名無しさん
04/01/24 03:14
>>120
ころころ挙動が変わらないようにプログラム組めば？
プロトタイプベースでももちろんできるけど。
挙動がころころ変わるような柔軟な処理も組めて、
挙動が変わらないプログラムも組める。
ところが、クラスがあると柔軟には組めない。
123:デフォルトの名無しさん
04/01/24 03:16
ていうか、Smalltalkには静的型チェック無いな。ｗ
クラスはあるが。
124:デフォルトの名無しさん
04/01/24 03:24
>>122
> ところが、クラスがあると柔軟には組めない。
どうして？例えばこのスレでも何度か話題に出てるSmalltalkなんかは
実行中にクラス定義を変化させたり、メソッドを定義したりできるじゃん。
それに1クラス1オブジェクトにすればプロトタイプベースと変わらなくなるし、
1クラス複数オブジェクトも可能な分だけ柔軟性があるとも言えるじゃないの？
つーかさ、クラスベースだからとかプロトタイプベースだからとかナンセンスでしょ。
柔軟性をキーワードにしたって、双方にそれぞれの利点と欠点があるわけでさ。
125:デフォルトの名無しさん
04/01/24 04:00
sumin さんとこの wiki に書き込めるようなレベルじゃない自分にとって、
このスレの議論は実にありがたい。
皆さん、どうかもっとガンガンやって下さい。
つうか、議論が長くなってくると、wiki より 2ch の方が見やすいなあ。
126:デフォルトの名無しさん
04/01/24 04:23
>クラスベースのアドバンテージですが、結局は型チェックの例と同様に、ある種の
>制約を課すことによる安心感、安定さ、安全性に尽きると思います。
>そんなにころころ挙動が
>変わったらドキュメント作る時どうするの。そんなふわふわ
>した言語でコーディングなんて出来ないよ
クラスベースの利点やプロトタイプベースの欠点は、抽象的にはこうした意見に
集約されるようですが、もっと具体的に知りたいです。
例えばSmalltalkは柔軟なのだからこれは当てはまらないのではないですか？
当てはまるとしたら具体的にどういった例が挙げられますか？
127:デフォルトの名無しさん
04/01/24 05:28
>>122-123
いや、そういう事じゃないんだけど・・・。
クラスがあるのは良いけど、クラスに色々盛り込み過ぎなんだよなぁ。
128:デフォルトの名無しさん
04/01/24 05:39
>>112
CLOS / MOP についてはここを読むといい。
URLﾘﾝｸ(www.geocities.co.jp)
URLﾘﾝｸ(www.shiro.dreamhost.com)
129:デフォルトの名無しさん
04/01/24 05:53
>>126
そんな理由で、Smalltalk を鼻にもかけない人や、プライベートプログラミングとしては
楽しいけど、仕事で使うのはちょっと…とためらう人が多いのではないでしょうか。
＞Smalltalk は柔軟だから当てはまらない
クラスベースの目指すところからしたら、Smalltalk や CLOS はさながら
鬼っ子か異端児といったところでしょうから、この二者が反例を呈すから、それは
クラスベースの特徴 or 制約ではないと言い出すと、ここでの対比や理解を深めることを
難しくしてしまうように思いますがいかがでしょう。
130:デフォルトの名無しさん
04/01/24 05:57
>>121
URLﾘﾝｸ(research.sun.com)
131:デフォルトの名無しさん
04/01/24 08:33
>>130
で、Smalltalk上にSelf(-like)環境を構築するのは困難とする根拠は？
132:デフォルトの名無しさん
04/01/24 10:15
>>130
SmalltalkじゃないけどRubyでSelfライクな環境を構築した例なら、ほれ。
すげー短いコードだし。
URLﾘﾝｸ(kumiki.c.u-tokyo.ac.jp)
133:1
04/01/24 13:38
オブジェクト指向は本当に「オブジェクト」指向か？]
URLﾘﾝｸ(www.ogis-ri.co.jp)
このスレ的にけっこう関係ありかと思われ．
単一分類と静的分類に縛られては素直なモデル化ができない．
上位工程では多重分類と動的分類をモデル化に用いて，
途中でそれを単一分類と静的分類に書き直し，
一般的なオブジェクト指向言語で実装する．
でもプロトタイプベースについては一言も触れられてないのが残念．
134:デフォルトの名無しさん
04/01/24 16:50
クラス指向 vs プロトタイプベースは結局 >>94 に集約されると思うが。
どちらが良いなんて無い。どちらが（自分の問題領域に）向いているかで
考えれば良い。
だいたい、オブジェクトシステムなんてこの 2 者以外にも色々モデルが
ある訳だし。
135:デフォルトの名無しさん
04/01/24 16:55
94って、意味がわからん。
なんか、大学受験の現代文の文章を読んでるかのごとく、
わかりにくい。
もっとこう、解説本のように具体例を挙げて説明してくれんかな。
136:デフォルトの名無しさん
04/01/24 17:37
>>94の日本語訳
プロトタイプベースはオブジェクトだけだが、クラスベースはいろんなクラスがある。
つまり、視点が違うんだ！
137:デフォルトの名無しさん
04/01/24 17:39
>>94
Classクラスのオブジェクトって？
138:Java厨
04/01/24 17:47
java.lang.Class hoge; //この変数に入れるオブジェクト
139:デフォルトの名無しさん
04/01/24 18:07
>>135
オブジェクト管理システムとして、クラスを使いたいかどうかって事でしょ。
クラスベースの場合、変数やメソッドの追加はクラスを通して行う。逆に言うと
オブジェクトの定義はクラスを見に行けば良い。オブジェクトはクラスの実体化
に過ぎないから、オブジェクト同士の比較やオブジェクトの型の保証等々はクラス
を使う事で簡単に実現出来る。
プロトタイプベースだと、変数やメソッドはオブジェクトローカルで自由に変え
る事が出来る。逆に、オブジェクトのメタな情報はそれぞれのオブジェクトが
バラバラに持っている（もちろんクラス相当のオブジェクトを作ってあげて、
そこに登録すれば良い訳だけど）。同じオブジェクトでもタイミングが違うと
全く異なる挙動をする可能性がある。
色々突っ込まれそう・・・。
140:デフォルトの名無しさん
04/01/24 23:00
> Smalltalk や CLOS はさながら鬼っ子か異端児
ｺﾞﾙｧ！勝手に異端扱いするんじゃねぇ！ どっちも OO システムとして
はかなり初期なんだから、むしろ後発の連中が静的ﾏﾝｾｰになっちまった
だけだろーが！
141:デフォルトの名無しさん
04/01/25 00:02
>>139
私もそういう考え。自信ないけど。
>>140
後発の言語のほうが、クラスベースの良さをよく理解していたのかもしれないよ。
142:デフォルトの名無しさん
04/01/25 02:57
>>141
> 後発の言語のほうが、クラスベースの良さをよく理解していたのかもしれないよ。
そうかな？ 型とクラスを安易に対応させる悪弊を撒き散らしたと思ってるけど。
ひどい時にはクラス＝型なんて話が出たりもする。
例えばJavaのインターフェース型なんて、プロトタイプベースでも十分可能でしょ？
つまり、型チェックのためにクラスを導入する必然性はないわけで。
143:Java厨
04/01/25 03:35
>>142
よろしければ、もう少し解説してくださらぬだろうか。
144:デフォルトの名無しさん
04/01/25 07:23
単純に、最適化しやすいほうが選ばれやすかったんだと思う。
で、 C/C++ が主流。
でも、変更に弱いとつらいってことが、少しずつ知られてきたよね。
computer の性能も、どんどん高くなってきた。
prototype-based とかも、これから見直されてくと思う。
145:デフォルトの名無しさん
04/01/25 09:48
>>142
クラスとオブジェクトはもともと Simula-67(のちにSimula)で、それぞれ「ユーザー定義
可能な型」とその「データ(インスタンス)」という位置づけてそう名付けられたものです。
C++はその流れを忠実に受け継いでいるので「クラス＝型」という考え方はなにも間違って
いないと思いますよ。
ただしこれはあくまで抽象データ型の話で、オブジェクト指向からはちょっと離れます。
C++はSmalltalkなどと違って抽象データ型言語としても使えるので、こういう話になります。
抽象データ型とオブジェクト指向でクラス定義や扱いがどう変わるかについては、
クックの論文によく整理されているので興味があればぜひ。
URLﾘﾝｸ(www.cs.utexas.edu)
146:デフォルトの名無しさん
04/01/25 12:27
>>145
> ただしこれはあくまで抽象データ型の話で、オブジェクト指向からはちょっと離れます。
その通り。
Simula-67ではデータ型とクラスが一緒くたになっていたが、
Smalltalkではそこからクラスとしての要素を抽出してpure OOにした。
ところがSimula以降の静的型付言語では、あいかわらずデータ型とクラスを
掛持ちさせている。
本来OOにおいてプログラマが気にするべきなのはJavaのインターフェース型のような
そのオブジェクトに可能な操作や観察としての型なわけだが、
処理系のほうはオブジェクトの内部構造のほうを要求していて
静的型付OO言語の設計では、処理系の都合のほうが常に優先されてきた。
効率を度外視すれば、クラスが存在しないプロトタイプベース言語でも
インターフェース型は導入可能で、それにより柔軟性をある程度手放して
実行前に型安全をチェックすることも可能でしょ。理論上は。
まあ、俺はクラスベースでもSmalltalkやPythonのような動的型付言語のほうが
好きな口なんで、静的型に縛られたプロトタイプベース言語なんて使わないと思うが、
インターフェース型ならばまだ妥協して使うかもしれない。
147:デフォルトの名無しさん
04/01/25 13:48
インターフェイスってクラスブラウザとリフレクションじゃダメなの?
実行時にレシーバのオブジェクトが何であるか決まるオブジェクトシステムで、
実行前に型チェックなんて出来ないでしょう。
148:デフォルトの名無しさん
04/01/25 14:57
>>144
> でも、変更に弱いとつらいってことが、少しずつ知られてきたよね。
そうなんだよ。JScriptだと、いきなりコードを書き始めて、少しずつ洗練させていくことが
できるんだけど、Javaだとあらかじめすごく考えてから書き始めないと、すぐ破綻
しちゃうんだよ。
これは自分の頭が悪いせいだと思ってたんだけど、下の文章を見て、ああ、そういう
ことなのかと思ったよ。
簡潔さは力なり
URLﾘﾝｸ(www.shiro.dreamhost.com)
芸術では、刺繍やモザイクといったメディアは何を作るかをあらかじめ知っていれば
うまくいくが、そうでなければめちゃくちゃになる。作りながらイメージを発見したい
のなら---例えば人物画のような複雑なイメージを扱いたい時はほとんどそうなのだが---
もっと柔軟性のあるメディア、鉛筆とかインク・ウオッシュ、あるいは油彩が必要だ
ろう。実際、タペストリーやモザイクは最初に画を描いてからそれをコピーすることで
作られている。
149:デフォルトの名無しさん
04/01/25 15:16
で、Java 世界でもこの「100％わかっている内容しかコーディングできない」という
のを問題とする人が増えてきて、その解決策としてリファクタリングが取り上げられる
ようになったんだと思うよ。
ファウラーの『リファクタリング』は基本的に、ずっとこんな感じ↓の内容で。
仕事に取り掛かった時点では、私はどういうクラス設計をしたらいいか、いつも
わからないんです。だから仕事に取り掛かるのがいつも怖かったんです。
だけどリファクタリングを知って、「とりあえず動くコードを書くことを目標に
しよう。設計はどうせまずいだろうけど、あとでリファクタリングできるから」
と考えるようになって、すごく安心しました。
この内容、私も本当に同感だったんだけど、>>148 のリンク先を見て、また別の感想を
持つようになったよ。
リファクタリングって、なんつうか、もともと変更に向かないモザイクのような言語で、
なんとか変更を行えるようにしたもの、という気がしてきたんだよ。
まあ、それなりに機能していると思うんだけど、モザイクを「15パズル」のように
いじっているような、もどかしさを感じてねえ。
URLﾘﾝｸ(www.game3rd.com)
150:デフォルトの名無しさん
04/01/25 15:57
>>147
まずは何かJavaの入門書を読んでinterface typeが何かを理解したら？
151:デフォルトの名無しさん
04/01/25 16:06
>>150
動的言語に適用した場合の具体的な実装とメリットがイメージ出来ないんだけど。
まぁ言い散らかすのは勝手だが。
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 だけあればいい、っていう。