- 1 名前：デフォルトの名無しさん [03/12/08 21:30]
- オブジェクトを複製または継承によって生成を行う言語，
プロトタイプベース・オブジェクト指向言語について語りましょうよ．
関連リンク >>2
- 41 名前：デフォルトの名無しさん mailto:sage [03/12/17 08:17]
- cecil やってる人がいるよ。
ttp://www.kmonos.net/alang/etc/cecil.php
- 42 名前：デフォルトの名無しさん [03/12/23 11:25]
- www.kmonos.net/alang/etc/cecil.php
- 43 名前：デフォルトの名無しさん mailto:sage [03/12/24 00:44]
- >41-42
>>3
- 44 名前：41 mailto:sage [03/12/24 01:16]
- >>43
書き込んでから気付いた・・・。
それにしても、スクリプト言語ばっかりだねぇ。
- 45 名前：デフォルトの名無しさん mailto:sage [03/12/24 13:51]
- ああっ、こんなスレッドができていた！
プロトタイプベースの言語はJScript（苦笑）しか知らないけれど、大好きだよ。
Javaの仕事をした後、JScriptを書いていると、その素晴らしい自由自在さに
コルセットが外れていくような解放感があるよ。
それと同時に、2chのJavaScriptスレッドの「すぐ目先の実用一点張り」な様子は
とても残念だよ。こんなにきれいで面白い言語なのに。
>>31
激しく同意。クラス導入に反対！
- 46 名前：デフォルトの名無しさん mailto:sage [03/12/25 16:35]
- Newtonもってる。だれかおもろいアプリ書いてくり！
- 47 名前：デフォルトの名無しさん [03/12/30 20:21]
- age tokuyo
- 48 名前：デフォルトの名無しさん mailto:sage [04/01/04 09:57]
- ttp://www.ipsj.or.jp/members/Trans/Jpn/03/2001/4211/article008.html
学校教育用オブジェクト指向言語「ドリトル」。Java 上で動くプロトタイプベース
言語らしい。
- 49 名前：デフォルトの名無しさん mailto:sage [04/01/04 10:01]
- ttp://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/seruby/
ついで。Ruby で実装した Self ライクな環境 SeRuby というのがあるらしい。
- 50 名前：デフォルトの名無しさん [04/01/04 13:27]
- >>48
LOGOのOO版みたいなもんですね．
論文は会員じゃなきゃ見れないので…
www.logob.com/dolittle/
- 51 名前：デフォルトの名無しさん mailto:sage [04/01/04 14:10]
- >>50
Squeakみたいだね
似たようなことアラン・ケイが小学生にさせてたのを教育テレビで見たことある
- 52 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 mailto:sage [04/01/07 07:40]
- 前のレス、最後のところは無しにして下さい。
println が、オブジェクトなのか、文字列オブジェクトに対するメッセージなのか、
出力先オブジェクトに対するメッセージなのか、言語によって捉え方が色々で
面白いなぁと。
調べてみたら、Smalltalk では「show: 'Hello World!'」で一つのメッセージという
カウントをしてるんですね。
- 55 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/01/07 08:37]
- あとちなみに、ECMAScript (3rd) だと、
obj = new Object() の参照するプロトタイプは
obj.prototype ではなく Object.prototype ではなく、 obj.[[prototype]]。
スクリプトからは明示的な読み出しも書き換えもできないので
困る、っちゅーのはその通り。
- 57 名前：52 mailto:sage [04/01/08 01:12]
- >>55-56
おお、詳しい方ですね！__proto__なんて、昔オライリーのサイ本でチラッと
目にして以来忘れていました。
NN7で試したら、動きました。今でもちゃんと動くんだなあ。
IEで動かないのが残念。
あつかましくて恐縮ですが、質問させてください。
1.obj.[[prototype]]の二重カッコはどういう意味なのでしょうか？
2.ECMAScriptは、どうしてプロトタイプを明示して読み書きできないという、
プロトタイプベースの発達の制限をしているのでしょうか？
どういう設計思想なのでしょう？
私はプロトタイプをもっと自由に使いたいのに。
- 58 名前：52 mailto:sage [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 mailto:sage [04/01/08 13:16]
- >>57
> 1.obj.[[prototype]]の二重カッコはどういう意味なのでしょうか？
「内部プロパティ」のつもり。意味論的にはオブジェクトのプロパティの
一つなんだけど、言語内では触ることのできないシロモノ。
www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/8_Types.html#section-8.6.2
> 2.ECMAScriptは、どうしてプロトタイプを明示して読み書きできないという、
> プロトタイプベースの発達の制限をしているのでしょうか？
実装の最適化のためだと思うよ。「あとから定義が変更できるクラス」
程度の柔軟性が残ってさえいれば、あとはできるだけ高速化しやすい
仕様を選んだんじゃないかと。知らんけど。
- 60 名前：52 mailto:sage [04/01/09 01:25]
- >>59
ありがとうございます。実装の最適化ですか…。
私は、クラスベースの言語の挙動に似せるためだと思っていました。
具体的にはJavaですね。
一般のプログラマは、非常に保守的ですから。
Java自体、最初はOAKという、FORTHに似た構文の言語だった時には全く人気が出ず、
Cに似た構文を採用してJavaとなってからやっと使われるようになったといいます。
（しかしJavaは5年ぐらいは、「ポインタ演算のできないC」として扱われた）
LiveScript -> JavaScriptも、Javaとの共通性を（ニセのイメージだとしても）打ち出さ
なければ、普及しなかったのじゃないかなと思うのです。
プロトタイプベースの言語は、そのシンプルな美しさに関わらず、いまや絶滅寸前
ですから。
あまりにも自由自在にすると、クラスベースにある堅牢さから遠ざかり、プログラマから
好まれないのではないか、と設計者が考えたのではないかと私は思っていました。
いずれにせよ、私は現状を残念に思います。今のECMAScriptは、貧者のJavaに過ぎない。
- 61 名前：デフォルトの名無しさん mailto:sage [04/01/09 02:52]
- 固く考えすぎだと思うんだけどなぁ。
「プロトタイプ指向かくあるべき」という先入観を捨ててから、もう数ヶ月ECMAScriptを使い込んでみて欲しい。
・ECMAScript は JavaScript(Netscape) と JScript(IE) の仕様摺り合わせとして
策定されたもの。そして JScript には __proto__ が実装されていなかった。それだけだ。
ECMAScript1.0が出た頃には、普及も何も、既にWWWのクライアントサイド言語としてシェアをほぼ全制覇していたし。
> プロトタイプベースの言語は、そのシンプルな美しさに関わらず、いまや絶滅寸前ですから。
・絶滅という言葉が使えるほど栄光の時代があったパラダイムではないと思うんだけど。
逆に今ならJavaScript があるし、ActionScript (Flash) がある。プロトタイプチェーンくらいはmetatableで
簡単に実装できるだけの柔軟性をもったLua言語も最近流行し始めた。
もちろん各言語のほとんどのユーザはプロトタイプ指向を用いては
いないだろうけど、それでもSelfしかなかった頃と比べたら、今や
プロトタイプな人の数は雲泥の差だ。
- 62 名前：52 mailto:sage [04/01/10 00:21]
- >>61
うーん、少々舌足らずだったかも知れません。
ECMAScriptがJavaScriptとJScriptのすり合わせで成立していることは承知している
つもりなのです。
ではなぜ、JScript、JavaScriptがこのような言語になったのでしょうか？
JScriptではプロトタイプはコンストラクタからしかアクセスできず、
JavaScriptでも__proto__は元々隠し機能であり、いつ廃止されるかわからない
状態だった。
それはやはり言語設計者が、プロトタイプを自由に扱わせることに、この言語の普及において
メリットよりデメリットを感じたからだと思うのです。馴染みにくいから。
また、そういうニーズは少ない。ネットを見回すと、JavaScriptでオブジェクト指向を
実現しようとする試みはたくさん見つかりますが、そのほとんどが「いかにしてJavaと
同じ事をするか」に腐心しています。それに対して、JScriptがプロトタイプを公開して
いないことに対する不満を主張するサイトは、私はまだ一度も見たことがありません。
プロトタイプベースの言語が世に広まってきたとは言え、そのほとんどのユーザにその意識が
無いままでは、いつまでも「Javaより貧弱な言語」と見なされるだけで終わってしまうのでは
ないかと思うのです。
- 63 名前：52 mailto:sage [04/01/10 00:22]
- などと大上段に構えたことを言っておりますが、実は私もつい数ヶ月前までは、プロトタイプ
ベースなんて意識することもありませんでした。
今書いたようなことは、Googleで偶然に
squab.no-ip.com:8080/wiki/search?search=%83v%83%8D%83g%83%5E%83C%83v&casesensitive=false&and=true
このあたりにたどり着いて、中途半端に感化されてしまっただけのことなんです。
すみません。
ただ、今まで オブジェクト指向 ＝ クラスベース としか思っていなかった私には、
まさに目からウロコだったのです。
プロトタイプによる委譲という単純な仕掛けだけで、クラスベースと同等以上の
記述性をもった言語が成立するというのが新鮮だったのですね。
年季の入った人からは稚拙な主張だと思います。
だから、皆さんがプロトタイプベースの言語とどのように付き合っているのか、
お聞かせ願えたらと思います。
例えば、ECMAScriptはこう書けば、このように自由なことができる、とか。
この言語は、このように便利だ、とか。
- 64 名前：デフォルトの名無しさん mailto:sage [04/01/10 19:53]
- 誰も使ってない
- 65 名前：デフォルトの名無しさん mailto:sage [04/01/10 21:53]
- 井戸の中に蛙が一匹
- 66 名前：デフォルトの名無しさん mailto:sage [04/01/10 22:46]
- 効率悪そうだな。
- 67 名前：デフォルトの名無しさん mailto:sage [04/01/15 19:58]
- 実行効率？なんで？
- 68 名前：デフォルトの名無しさん [04/01/15 19:59]
- でも、大規模システムの開発効率は悪そうだな。型機能が不足な分。
- 69 名前：デフォルトの名無しさん [04/01/15 20:05]
- いまIoとか絶滅どころかめちゃめちゃアクティブじゃんよ
- 70 名前：デフォルトの名無しさん mailto:sage [04/01/15 21:14]
- >>45
JavaScriptは、使われ方からユーザがほとんど厨ユーザだからね。
おまいみたいなヤシばっかだったらいいのに。
- 71 名前：デフォルトの名無しさん mailto:sage [04/01/15 21:39]
- あっちのスレは、Web政策版と棲み分けようと努力しているよ。
あとからあとから厨が乱入してくるけど。
- 72 名前：デフォルトの名無しさん mailto:sage [04/01/15 22:20]
- 他人がスクリプトをどう使うかについて文句を言える筋合いはないが、
実用本位で使うから房っていうのは（もしその意図があるなら）頂けないな。
まあ高邁な学者さんのようなご意見だとは思うけどね。
- 73 名前：デフォルトの名無しさん mailto:sage [04/01/16 23:06]
- >>66
Self は JIT で結構速いらしいよ。
プロトタイプ言語のオーバーヘッドは結構大きそうな感じはするけどね。
- 74 名前：デフォルトの名無しさん [04/01/19 02:27]
- >>72
そうばかりは言えないよ。あなただって、Java で COBOL みたいなコーディングを
している人がいたら「もうちょっと言語を理解して使ったほうがいいんじゃないの？」
と思うでしょ？
- 75 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/01/19 02:35]
- >>72
厨なコードを「実用本位」と呼ぶことは、本当に実用になるコードを書く職人さんに失礼。
- 77 名前：75 mailto:sage [04/01/19 02:40]
- こう書くと、デザパタに慣れた人は、
これが FactoryMethod パターンと State パターンを組み合わせたものに
近い、と感じられないかな。
a と b が State ね。
オブジェクト指向言語には、既存のオブジェクトの機能を利用して新しいオブジェクトを
作る方法が、大きく分けると2つある。「継承」と「委譲」。
クラスベースの言語は、言語レベルで「継承」をサポートし、
プロトタイプベースの言語は、言語レベルで「委譲」をサポートしたものだと
言えると思う。
上と似た動作のコードは Java でも書けるけど、かなり煩雑になる。
- 78 名前：75 mailto:sage [04/01/19 02:56]
- ということで、蛇足なんだけど、
JavaScriptは、せっかく言語レベルで委譲をサポートしているのだから、委譲を中心に
活用するのが良いと思う。
Java の真似をして、継承という枠組みで使うのは、無理があるし、もったいない。
- 79 名前：デフォルトの名無しさん mailto:sage [04/01/19 03:18]
- 委譲っていう概念自体が、既存の静的なクラスをベースとした言語を基礎にしてる
気がする。
- 80 名前：デフォルトの名無しさん mailto:sage [04/01/19 04:12]
- >>79
なんで？クラスなんて全然関係ないじゃん。
- 81 名前：79 mailto:sage [04/01/19 07:48]
- >>79
s/言語を基礎に/言語を背景に/
- 82 名前：デフォルトの名無しさん mailto:sage [04/01/19 23:32]
- 意味不明．
委譲の発祥がクラスベースって言うんだったら
そもそも最初のOOPLがクラスベースだったんだから(ry
- 83 名前：デフォルトの名無しさん mailto:sage [04/01/20 01:12]
- クラスベースの多重継承の代替物というイメージが強いからじゃ？
そもそも漏れみたいな厨は、それが委譲のオリジンだと思ってた。
- 84 名前：デフォルトの名無しさん mailto:sage [04/01/20 03:04]
- 継承と委譲についてだけど、どちらも、
「あるオブジェクトが、自分の実装していない機能があったとき、別のオブジェクトから
それを借りてくる」
という点では変わらない。
で、継承は、オブジェクトを作る金型（クラス）の間で、機能の貸し借りをするの
だけど、
委譲は、実際に生成されたインスタンスの間で、機能の貸し借りが行われる。
型なし言語（だった）JavaScriptが委譲を採用しているのは、まあ当然かも。
- 85 名前：デフォルトの名無しさん mailto:sage [04/01/20 03:09]
- >>84
> 型なし言語（だった）JavaScriptが委譲を採用しているのは、まあ当然かも。
型とクラスが混ざってないかい？
- 86 名前：デフォルトの名無しさん mailto:sage [04/01/20 03:23]
- あと、無粋なツッコミですまんが、>>83
プロトタイプ・チェインはむしろ単一継承にたとえられることが多いはず。
多重継承は、一回の継承で複数個の親クラスを持つことでしょ？
歴史的経緯については私も知らない。すまん。
- 87 名前：デフォルトの名無しさん mailto:sage [04/01/20 03:28]
- >>86
あー、俺は83じゃないが、たぶん83が言いたいのは、
単一継承のOOPLで多重継承的なことをやるために委譲が使われた、
みたいな感じのことだと思われ。
- 88 名前：デフォルトの名無しさん mailto:sage [04/01/20 03:29]
- >>85
ん？あなたが言っている型というのは、プリミティブ変数の型のことかい？
私はクラスを、オブジェクトの型として構わないと思うのだけど。
さしさわりがあったら、教えてほしい。
- 89 名前：デフォルトの名無しさん mailto:sage [04/01/20 03:32]
- >>87
なるほど、了解。これは私の読み違いだったか。
- 90 名前：デフォルトの名無しさん mailto:sage [04/01/20 03:35]
- >>88
例えばJavaにはオブジェクトの型としてインターフェイス型なんてものあるねえ。
ついでに言えば、Smalltalkはいわゆる型なし言語(正確には動的型付言語)
と言われているが、コテコテのクラスベースOOPLだよ。
- 91 名前：デフォルトの名無しさん mailto:sage [04/01/20 03:47]
- >>90
ええと、私は「型」というものを、「変数の、ある機能を保証するもの」と
見なしている。例えば、数値型だったら、四則演算が保証される、というように。
同様に、例えばあるインスタンスがコレクション・インターフェースに属していたら、
それはイテレータによる処理が保証されるわけだから、これをオブジェクトの
型とみなして良いと考えていた。
それに対して、プロトタイプベース言語は、実行するまでその操作が可能か、事前には
分からない。型による保証がない。
こういうイメージで、クラス（ないしはインターフェース）を「型」の一種と考えている
んだけど、まずいだろうか？
- 92 名前：デフォルトの名無しさん mailto:sage [04/01/20 04:03]
- >>90
Smalltalk については、知らないのでなんとも言えない。
だけど、型なし言語だったら、プロトタイプベースのほうが自然なんではないか
という気がする。オブジェクトの機能の貸し借りに、クラスというものを介在
させずにすむから。
ということで、機会があったら、勉強してみます。
- 93 名前：デフォルトの名無しさん mailto:sage [04/01/20 04:15]
- class と interface とが異なるってことだと思う。
class は C++ みたいな言語での、継承の階層図での位置だよね。
対して interface は、 method とかの集合だと思う。
静的で class-based な言語なら一意に対応するだろうけど、
動的な言語だと interface だけ変えるとか、 class だけ変えるとかができそう。
- 94 名前：デフォルトの名無しさん mailto:sage [04/01/20 04:53]
- >>92
> だけど、型なし言語だったら、プロトタイプベースのほうが自然なんではないか
> という気がする。オブジェクトの機能の貸し借りに、クラスというものを介在
> させずにすむから。
どうだろうね。
プロトタイプベースではオブジェクトの型紙としての機能を全オブジェクトに持たせるのに対して、
Smalltalkではオブジェクトの分担をはっきりさせ、
Classクラスのオブジェクトにその機能を集中させて専業させることで
その他のオブジェクトを簡素化している、
とも言えるわけで、
全てのオブジェクトにオブジェクト生成機能を持たせるSelfと
オブジェクト生成機能を特定のオブジェクトに専門化させたSmalltalk。
つまり
比較的単質なオブジェクトの集合としてオブジェクト世界を構築するSelfと
色々な種類のオブジェクトの集合としてオブジェクト世界を構築するSmalltalk。
その一方で、
固定的な種別を排除した雑多なオブジェクト世界を構築するSelfと
クラスという明確な種別による整然としたオブジェクト世界を構築するSmalltalk。
結局はコインの表裏ってとこだよ。
どっちが自然というよりは、モデリングの視点が違っているだけの話だと思う。
あとは趣味の問題。
- 95 名前：デフォルトの名無しさん mailto:sage [04/01/20 08:38]
- オブジェクト生成機能って、new とか init, alloc, clone みたいなの?
- 96 名前：デフォルトの名無しさん mailto:sage [04/01/20 09:00]
- >>95
まあそんなもの。
属性名とスロットインデックスの対応とかメソッド辞書等の、
オブジェクトの構造や機能に関する情報と、
それを使ってオブジェクトを生成する操作。
- 97 名前：デフォルトの名無しさん mailto:sage [04/01/20 17:51]
- >>94-96
なるほどねえ。
プロトタイプベースについて論じるためには、実はクラスベースについても
広くきちんとした知識をもっていなければならないのだなあ。
勉強になりました。
- 98 名前：デフォルトの名無しさん mailto:sage [04/01/20 17:57]
- ということで、ややスレ違いで恐縮なんだけど、
>>93のように、Smalltalk って、インスタンスの属するクラスをを動的に変更
できるの？まさか、キャストのことじゃないよね？
インスタンスが生成されたあとでも、その属するクラスを動的に変更できると
したら、プロトタイプベースと同等の自由度だよね？にわかに信じがたい。
もし本当なら、Javaでは信じられない世界だ。
- 99 名前：デフォルトの名無しさん mailto:sage [04/01/20 21:42]
- >>97
ここら辺が参考になるかと。
ttp://www.shiro.dreamhost.com/scheme/docs/schemersway-j.html
ttp://homepage.mac.com/mkino2/oop/index.html
>>98
CLOS ではオブジェクトが属するクラスを後から変えられるみたい。
Smalltalk では become: というメソッドがあったらしい。
ttp://www.sra.co.jp/smalltalk/SML/archives/2001-August/005283.html
ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/11398
ttp://homepage.mac.com/mkino2/oop/methodAddition.html
>その属するクラスを動的に変更できると
>したら、プロトタイプベースと同等の自由度だよね？
サブクラシングせずに、オブジェクト毎にメソッドを追加／上書き出来ないと
同等じゃないと思う（個人的には）。
私はプログラマでも言語実装者でもないので、全部伝聞でｽﾏｿ。
- 100 名前：1 [04/01/20 23:39]
- 100.get!
- 101 名前：1 mailto:sage [04/01/20 23:45]
- >その属するクラスを動的に変更できると
>したら、プロトタイプベースと同等の自由度だよね？
そこまでしてクラスに拘る理由があるのか疑問．
そうやってどんどんクラスベースに柔軟性を持たせると，
結局プロトタイプベースと同じものになるだろう．
そうなったらクラスという概念が無い方がシンプルでわかりやすい．
自由度と危険性を手に入れたいならクラスという概念はいらないはず．
- 102 名前：デフォルトの名無しさん mailto:sage [04/01/21 00:03]
- オブジェクト to オブジェクトのトランスレートなんて頻繁に起こる物じゃないから、
基盤をクラスに置く事は何の不思議もないと思うけど。
- 103 名前：デフォルトの名無しさん mailto:sage [04/01/21 01:51]
- >>102
そうかな？
あるオブジェクトのインスタンスがあって、モードによってその動作を
ガラッと変えたい、なんて場合には、ぜひとも既存のインスタンスの
属すクラスを、別のものに変えたいと思うけどなあ。
GUI の設計とかしていると、よくそういうことない？
というか、Java でよく使う Stateパターンって、動的にクラスの
変更のできない言語で、委譲先を変えることによって機能をそっくり
取り替えてしまおう、というものでしょ？
（まあ、メソッドの内容は変えられても、シグナチャは変えられないんだけど）
ということで、今はそんなにクラスの変換は行われていなくても、もし言語が
それをサポートしているなら、需要はいくらでもあると思う。
- 104 名前：デフォルトの名無しさん mailto:sage [04/01/21 01:53]
- >>103
自己訂正。
State パターンで変えられないのはシグナチャ、という言い方は不適切だな。
メソッド自体を新設したり、廃止したりということはできない、とすべきだった。
- 105 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/01/21 02:51]
- >>105
素晴らしい！Smalltalk ってそんなに自由なのか！
クラスベースにも、こういう可能性があったのですね！
こんなJava厨の質問に答えてもらって申し訳ない。
ありがとう、>>105の中の人！
- 107 名前：Java厨 mailto:sage [04/01/21 04:22]
- オブジェクトの各変数（フィールド）はどうなるの？
- 108 名前：デフォルトの名無しさん mailto:sage [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 mailto:sage [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 mailto:sage [04/01/21 12:47]
- 成り行きとはいえ、スレ違いのSmalltalkネタを書きすぎました。
スレ汚しスマソ。
- 111 名前：デフォルトの名無しさん mailto:sage [04/01/21 21:28]
- >>110
いや、ちっとも迷惑じゃないです。
ということで、>>107 について簡単でよいから教えていただけませんか？
私も知りたい。
- 112 名前：デフォルトの名無しさん mailto:sage [04/01/21 22:53]
- CLOS についても聞きたいっす。名前だけは見かけるんだけど。
実際どうなんでしょ？柔軟性という点ではプロトタイプベースとタメを
はれるんでしょうか？
- 113 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/01/22 16:16]
- とある知り合いの言うことには、
「クラスベースのオブジェクト指向言語は
リファレンスマニュアルが書きやすいからいいんだよ」
とても納得した。
- 117 名前：デフォルトの名無しさん mailto:sage [04/01/23 03:49]
- >>114-115
予備知識がなくて難しいですが、ある程度分かった気がします。
become: というのは、他のインスタンスを自分のアドレスにコピーすることなのですね？
それなら、オーバーヘッドが大きいのも分かります。
from: の実装次第で、どのようなクラスに変えることができるのも分かりました。
>>108-109 については、正直「なんとなく分かった？」程度ですが、自分としては
一応満足です。さすがにこれ以上はスレ違いでしょうし。
丁寧にご説明いただき、大変ありがとうございました。
- 118 名前：デフォルトの名無しさん mailto:sage [04/01/24 00:10]
- プロトタイプベースに対するクラスベースの優位性ってなんですかね？
その一つは型チェックだと思うんだけど、Smalltalkのようなインタプリタだと
その利点もなくなるし、結局なにがいいのかな？
- 119 名前：デフォルトの名無しさん mailto:sage [04/01/24 01:56]
- >>118
Smalltalk言語処理系は基本的にコンパイラベースです。Smalltalk環境内であまりに
自在にコードを評価できるので勘違いされがちですが…。いちおう、念のため。
クラスベースのアドバンテージですが、結局は型チェックの例と同様に、ある種の
制約を課すことによる安心感、安定さ、安全性に尽きると思います。
クラスベースとプロトタイプベースをコインの表裏、テーゼとアンチテーゼのように
例える向きもありますが、それよりむしろ、クラスベースはプロトタイプベースが実現できる
システム形態のひとつだと考えるほうがいろいろなことをうまく説明できます。
Smalltalk 処理系を Self で比較的すなおに実装できるのに対して、逆はそうでは
ないことなどは、その良い例でしょう。
- 120 名前：デフォルトの名無しさん mailto:sage [04/01/24 02:53]
- -- プロトタイプベース言語、何それ?
ふーん、クラス無いの。静的型チェックも出来ないんだ。
オーバーヘッドも大きそうだし、そんなにころころ挙動が
変わったらドキュメント作る時どうするの。そんなふわふわ
した言語でコーディングなんて出来ないよ。学者さんの研究
じゃないからね。こっちは仕事で納めるコードを書いてるんだ。
って言われない事。
- 121 名前：デフォルトの名無しさん mailto:sage [04/01/24 02:58]
- >>119
> Smalltalk 処理系を Self で比較的すなおに実装できるのに対して、逆はそうでは
> ないことなどは、その良い例でしょう。
んなわきゃない(苦笑
- 122 名前：デフォルトの名無しさん mailto:sage [04/01/24 03:14]
- >>120
ころころ挙動が変わらないようにプログラム組めば？
プロトタイプベースでももちろんできるけど。
挙動がころころ変わるような柔軟な処理も組めて、
挙動が変わらないプログラムも組める。
ところが、クラスがあると柔軟には組めない。
- 123 名前：デフォルトの名無しさん mailto:sage [04/01/24 03:16]
- ていうか、Smalltalkには静的型チェック無いな。ｗ
クラスはあるが。
- 124 名前：デフォルトの名無しさん mailto:sage [04/01/24 03:24]
- >>122
> ところが、クラスがあると柔軟には組めない。
どうして？例えばこのスレでも何度か話題に出てるSmalltalkなんかは
実行中にクラス定義を変化させたり、メソッドを定義したりできるじゃん。
それに1クラス1オブジェクトにすればプロトタイプベースと変わらなくなるし、
1クラス複数オブジェクトも可能な分だけ柔軟性があるとも言えるじゃないの？
つーかさ、クラスベースだからとかプロトタイプベースだからとかナンセンスでしょ。
柔軟性をキーワードにしたって、双方にそれぞれの利点と欠点があるわけでさ。
- 125 名前：デフォルトの名無しさん mailto:sage [04/01/24 04:00]
- sumin さんとこの wiki に書き込めるようなレベルじゃない自分にとって、
このスレの議論は実にありがたい。
皆さん、どうかもっとガンガンやって下さい。
つうか、議論が長くなってくると、wiki より 2ch の方が見やすいなあ。
- 126 名前：デフォルトの名無しさん mailto:sage [04/01/24 04:23]
- >クラスベースのアドバンテージですが、結局は型チェックの例と同様に、ある種の
>制約を課すことによる安心感、安定さ、安全性に尽きると思います。
>そんなにころころ挙動が
>変わったらドキュメント作る時どうするの。そんなふわふわ
>した言語でコーディングなんて出来ないよ
クラスベースの利点やプロトタイプベースの欠点は、抽象的にはこうした意見に
集約されるようですが、もっと具体的に知りたいです。
例えばSmalltalkは柔軟なのだからこれは当てはまらないのではないですか？
当てはまるとしたら具体的にどういった例が挙げられますか？
- 127 名前：デフォルトの名無しさん mailto:sage [04/01/24 05:28]
- >>122-123
いや、そういう事じゃないんだけど・・・。
クラスがあるのは良いけど、クラスに色々盛り込み過ぎなんだよなぁ。
- 128 名前：デフォルトの名無しさん mailto:sage [04/01/24 05:39]
- >>112
CLOS / MOP についてはここを読むといい。
ttp://www.geocities.co.jp/SiliconValley-Oakland/1680/clisp/index.html
ttp://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi
- 129 名前：デフォルトの名無しさん mailto:sage [04/01/24 05:53]
- >>126
そんな理由で、Smalltalk を鼻にもかけない人や、プライベートプログラミングとしては
楽しいけど、仕事で使うのはちょっと…とためらう人が多いのではないでしょうか。
＞Smalltalk は柔軟だから当てはまらない
クラスベースの目指すところからしたら、Smalltalk や CLOS はさながら
鬼っ子か異端児といったところでしょうから、この二者が反例を呈すから、それは
クラスベースの特徴 or 制約ではないと言い出すと、ここでの対比や理解を深めることを
難しくしてしまうように思いますがいかがでしょう。
- 130 名前：デフォルトの名無しさん mailto:sage [04/01/24 05:57]
- >>121
ttp://research.sun.com/research/self/release_4.0/smalltalk.html
- 131 名前：デフォルトの名無しさん mailto:sage [04/01/24 08:33]
- >>130
で、Smalltalk上にSelf(-like)環境を構築するのは困難とする根拠は？
- 132 名前：デフォルトの名無しさん mailto:sage [04/01/24 10:15]
- >>130
SmalltalkじゃないけどRubyでSelfライクな環境を構築した例なら、ほれ。
すげー短いコードだし。
ttp://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/seruby/
- 133 名前：1 mailto:sage [04/01/24 13:38]
- オブジェクト指向は本当に「オブジェクト」指向か？]
www.ogis-ri.co.jp/otc/hiroba/technical/Classification/index.html
このスレ的にけっこう関係ありかと思われ．
単一分類と静的分類に縛られては素直なモデル化ができない．
上位工程では多重分類と動的分類をモデル化に用いて，
途中でそれを単一分類と静的分類に書き直し，
一般的なオブジェクト指向言語で実装する．
でもプロトタイプベースについては一言も触れられてないのが残念．
- 134 名前：デフォルトの名無しさん mailto:sage [04/01/24 16:50]
- クラス指向 vs プロトタイプベースは結局 >>94 に集約されると思うが。
どちらが良いなんて無い。どちらが（自分の問題領域に）向いているかで
考えれば良い。
だいたい、オブジェクトシステムなんてこの 2 者以外にも色々モデルが
ある訳だし。
- 135 名前：デフォルトの名無しさん mailto:sage [04/01/24 16:55]
- 94って、意味がわからん。
なんか、大学受験の現代文の文章を読んでるかのごとく、
わかりにくい。
もっとこう、解説本のように具体例を挙げて説明してくれんかな。
- 136 名前：デフォルトの名無しさん mailto:sage [04/01/24 17:37]
- >>94の日本語訳
プロトタイプベースはオブジェクトだけだが、クラスベースはいろんなクラスがある。
つまり、視点が違うんだ！
- 137 名前：デフォルトの名無しさん mailto:sage [04/01/24 17:39]
- >>94
Classクラスのオブジェクトって？
- 138 名前：Java厨 mailto:sage [04/01/24 17:47]
- java.lang.Class hoge; //この変数に入れるオブジェクト
- 139 名前：デフォルトの名無しさん mailto:sage [04/01/24 18:07]
- >>135
オブジェクト管理システムとして、クラスを使いたいかどうかって事でしょ。
クラスベースの場合、変数やメソッドの追加はクラスを通して行う。逆に言うと
オブジェクトの定義はクラスを見に行けば良い。オブジェクトはクラスの実体化
に過ぎないから、オブジェクト同士の比較やオブジェクトの型の保証等々はクラス
を使う事で簡単に実現出来る。
プロトタイプベースだと、変数やメソッドはオブジェクトローカルで自由に変え
る事が出来る。逆に、オブジェクトのメタな情報はそれぞれのオブジェクトが
バラバラに持っている（もちろんクラス相当のオブジェクトを作ってあげて、
そこに登録すれば良い訳だけど）。同じオブジェクトでもタイミングが違うと
全く異なる挙動をする可能性がある。
色々突っ込まれそう・・・。
- 140 名前：デフォルトの名無しさん mailto:sage [04/01/24 23:00]
- > Smalltalk や CLOS はさながら鬼っ子か異端児
ｺﾞﾙｧ！勝手に異端扱いするんじゃねぇ！ どっちも OO システムとして
はかなり初期なんだから、むしろ後発の連中が静的ﾏﾝｾｰになっちまった
だけだろーが！
- 141 名前：デフォルトの名無しさん mailto:sage [04/01/25 00:02]
- >>139
私もそういう考え。自信ないけど。
>>140
後発の言語のほうが、クラスベースの良さをよく理解していたのかもしれないよ。
|
 |
