{_proto: プロトタイプベース・オブジェクト指向};

実装談義も哲学論議も。


プロトタイプベース・オブジェクト指向とは　http://sumim.no-ip.com:8080/wiki/493
Google Directory Prototype-based　http://directory.google.com/Top/Computers/Programming/Languages/Object-Oriented/Prototype-based/
Self　http://research.sun.com/research/self/
Io　http://www.iolanguage.com/
ほか　>>2-10あたり

前スレ
　プロトタイプベース・オブジェクト指向
　http://pc5.2ch.net/test/read.cgi/tech/1070886635/

Cecil
http://www.cs.washington.edu/research/projects/cecil/www/index.html
http://www.kmonos.net/alang/etc/cecil.php

Cel
http://www.redwoodsoft.com/cel/

soopy
http://soopy.sourceforge.jp/tutorial/soopyindex.html

Water
http://www.waterlanguage.org/

OScheme
http://koala.ilog.fr/abaird/oscheme/oscheme.html

Agora
http://prog.vub.ac.be/research/agora/

Brain
http://brain.sourceforge.net/

Obliq
http://www.luca.demon.co.uk/Obliq/Obliq.html

ECMAScript
http://www.ecma-international.org/publications/standards/Ecma-262.htm

NewtonScript
http://wsmith.best.vwh.net/works.html
http://www.cc.gatech.edu/~schoedl/projects/NewtonScript/

Io 文書Io Documentation
http://f21.aaa.livedoor.jp/~kizz/prog/io/Docs_ja.html

プログラミング言語 Io のはなし
http://shinh.skr.jp/io/

SELF: The Power of Simplicity (和訳)
http://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html

＃原文はいずこ。。。？

NewtonScript
http://www.k-inet.com/~brown/ftp/newton/Documents/NewtonScript.pdf
http://www.kallisys.com/newton/einstein/ (Projet Einstein)

SELF and the Origins of NewtonScript
This is an introduction to the paper "Self: the power of simplicity", by Ungar and Smith.
http://wsmith.best.vwh.net/Self-intro.html

ruby並に普及すればいいね。まあ無理だろうけど。

Luaは違うのか

>>7
Rubyも特異メソッドに注目すればプロトタイプベースだよ。
http://ruby.mirror.easynet.be/ja/uguide/uguide16.html
http://mput.dip.jp/?date=20030912

うーん、だからそういうあんま共通点のない言語の集めてどうすんだよ。
プロトタイプならでわの話題があるわけでもなし。
ここでいままでされてきた話って、そういう風にも組めますね、だから何？
で終わりじゃないか。
プロトタイプベースにしたらプロジェクトに成功したとか、金持ちになったとか、
こんなメリットがあった、みたいな話を聞きたいな。

うーん、だからそういうあんま共通点のない言語の集めてどうす
んだよ。 プロトタイプならでわの話題があるわけでもなし。
ここでいままでされてきた話って、そういう風にも組めますね、だから何？
で終わりじゃないか。 プロトタイプベースにしたらプロジェクトに成功し
たとか、金持ちになったとか、 こんなメリットがあったよ、みたいな話を聞きたいな。

＞あんま共通点のない言語の集めてどうすんだよ。
＞プロトタイプならでわの話題があるわけでもなし。

だったら前スレは1000まで全うせんかっただろう。

まあ、POOのメリットを探るってのは欲しいな。
金持ちになれるかどうかは置いといてｗ

プロトタイプベース・オブジェクト指向って
JavaScriptのことだろ。
すでに十分普及している。

> クラスでの定義の具体例（インスタンス）としてオブジェクトを
> 生み出すのではなく、既存のオブジェクトの複製（クローン）、
> あるいは、それへの参照を持つことですべてを委譲する
> オブジェクト（チャイルド）を生み出す手法で

あーだめだ。今チャイルドと聞くと舞HiME思い出してしまう。
終わってから忘れるまであと半年ぐらいまってくれ。

POOてなんだよ。
馬鹿にしてるのッ！

ﾌﾟｰ

>>16
プルートのことかーーー！

ぷーはメリットよりデメリットの方が多そうだが

>>18
タブーを犯すと刈られるしな。

まあ、実質JavaScriptスレなわけだが。

http://jp.rubyist.net/magazine/?0002-WCNewsPaper#l7
POOのメリットを活用しているRubyは、オライリーも出るほど普及してる。

どうせTraitsがなきゃやってられないんだから、
原理主義に陥らずメリットをうまく活かすのが吉かと。

オライリーも、それほどネタに困っているということだな。

可読性とかについて語りたい。

個人的にはパスタをおいしく作る方法にしか見えない。

>>20
巣に帰れ

>>23
POOがなぜ可読性を下げると？
まあ、メソッドの定義がどれかってのを追うのはあれかな。

とりあえずPOOがどんなものか
語れ。

>>25
23じゃないが、つまり、処理を追わないとオブジェクトが
どんな機能を持つかわからないという事じゃないかな。

これはドキュメントを書くときにも困る。
静的型ならデータ型と、メソッドについて書いていけばいいが、
プーだと処理についても言及しなければならない。

処理を追わないとわからないというのは、使い所を誤ってないかな?
Ruby等でもクラス/インスタンス特異を 無闇に 使ってると可読性が落ちるのと一緒。

>>28
得意メソッドの正しい使い方を教えてください。
標準ライブラリのstringクラス拡張する奴とかがそれ？

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/25772
こいつが猛烈に欲しいのですが……

>処理を追わないとわからないというのは、使い所を誤ってないかな?

クラスとプロトタイプなオブジェクトと、両方が使えるんなら「使い所を誤ってないかな?」
という反論が有効だけど、そもそもクラスがない言語じゃどうしようもないよねえ。

なんかこう、クラスなんかなくてもいいぜ! 的なパラダイムシフトを求めてたんだが。
無理な話?

>>31
関数型言語いじってみると結構パラダイムシフトするかもよ

つーか（呼び方はともかくとして）プロトタイプベースだからクラスはないってことはないぞ。

>>32
インスタンスの初期のメソッドのセットを定義するもの。

とか地味な存在になる感じですか？

この場合の、プロトタイプで用いるクラスってのは、

オブジェクトをハッシュデータ構造と考えて、
コンストラクタ ... 自分自身のクローン/コピーを返すメソッド
継承 ... データのマージ

程度で十分じゃないかな。フルセットの"クラス"は実装されてない言語もあるが、
クラスに相当するオブジェクトを作れば、プロトタイプでも従来どおりの記述が出来る。

ハッシュって、テーブルでリソース食いまくりな気がするんだけど、
そういうのは無視？

>>35
関係ない

>>36
何が？

ハッシュル！ハッシュル！

protoとparentの違いがやっと分った。
protoは意味上の親を表わし、
parentは構造上の親を表わすわけね。

しかしparentはGUIのイベント伝播以外に使いどころが
あるのだろうか？

こんな中途半端な概念の物やるよりはhaskellとか関数型言語やった方がいいよ

HaskellでGUIはきついぞ？

そうか？
そうか・・・

>>40
プロトタイプベースが中途半端だということですか？
クラスベースは中途半端ではないのですか？
どこが中途半端なのか教えてください。

>>43
関数型言語と言ってるからクラスベース言語とは関係無いでしょう。
何かと言うとクラスベースを持ち出したがるのはこのスレの悪いクセだな。

>>40
プロトタイプベース言語もそれなりにとんがっている言語だと思うよ。
歴史的には Lisp/Scheme とかとクロスオーバーしている部分もあるし。

>>44
プロトタイプベースOOのスレなんだから、比較対象としてクラスベースが
持ち出されるのはむしろ必然で、
こんなとこで脈絡なくHaskellを持ってくる方が、関数型言語ヲタクの
悪いクセだと思われ。

過剰反応だろ

多分、動的な型の扱いはまだ研究途上だから、
それより素性のはっきりしたHaskellでもやっとけ、
と言いたいんじゃないの？

関数型でも型付きな言語が出てきたのは後からだべ

ぱす。

309 名前： デフォルトの名無しさん 投稿日： 2005/05/19(木) 21:44:36
けれどクラスという概念をなくしてしまってもいい
オブジェクトの構造・仕組みという抽象的なもので
コード上は現れないようにしても問題ないだろうよ

311 名前： デフォルトの名無しさん [sage] 投稿日： 2005/05/20(金) 06:01:04
>>309
そういう道を進んでいる言語もある。
プロトタイプベースと呼ばれているようだが。

さて、プロトタイプるとするか


ぷ
ろ
と
たいぷ

nanika

ただいまのぷー儲数：０


ﾌﾟｰﾌﾟﾌﾟﾌﾟ

オンザフライでメソッドを追加出来るのは今でも魅力的だと思ってる

結局は、オブジェクトの定義が動的か静的かって事じゃないの？
クラス継承もインスタンス化も、プロトタイプからの生成も、is-a関係と考えれば、
クラス定義が動的（タイミングが実行時という意味でなく、組み立て可能という意味）
に出来れば、クラスのありなしって、関係ないんじゃね？
CoR云々て、そんなのを中心としたコーディングなんて有り得ないっしょ？
CoR Orientedなんて方法論が確立され無い限り（されるとは思えんが）。

あらゆるオブジェクトがクラスであるようなクラスベースなら、プロトタイプベースと同じだね。
そうじゃなくて、毎回クラスとインスタンスを別に作らなきゃいけないとかだと、ちょっと面倒かな。

# プロトタイプからの生成は、 is-a 関係じゃなくても使うよ。兄弟とか。

ぷー儲じゃないけど
いじくる必要のないところは効率よくやってほしいもんだ

つまり効率優先派とは常に衝突するな

http://d.hatena.ne.jp/m-hiyama/
プログラマのためのJavaScript (7)-

↑JavaScriptのオブジェクト周りが丁寧に解説されてます。
知らない人はぜひこの機会に読んでみては。

# トレイツベースと呼ぶのはどうでしょ？

ここは馬鹿の巣窟だな

>>59
あなたがTraitsを知らないことだけはよく分かりました。

トレイトとクラスの違いがわかんないな。大した違いはないはずだけど

>>61

やろうとしていることは同じです。
共通項の括り出しですね。

で共通部分と特有部分の関係を静的に表現するか動的に表現するかという違いではないでしょうか。
静的な表現がクラス-インスタンスで、動的な表現がトレイツ+オブジェクト。
POOのトレイツは単なる役割なので構造的にはクラスベースよりシンプルですね。
クラスベースの場合、インスタンスとクラスの違いは呼び方だけではなくって中身が違いますからね。

特定の名前スロットを特殊な使い方(_PROTO_とか）するところだけがなじめないんだけど、そういう実装以外ないのかな？

>>63
JavaScriptのことかな。
プロトタイプのようなしくみがないと自動委譲(=トレイツ)ができないけど、
それでもない方が良いということですか？
それとも何か別の案があるんですかね。

POOなんてアフォなのやめて
プロパティ指向にしたらどうだ

>>64
そういう意味じゃなくて特定の名前スロットが特定の意味を持たされている部分がなにか嫌らしい感じしません？
ＣＰＵで言うところの特定のレジスタだけが特別扱い的なマシン特性の泥臭さがでてると言うか。
名前に機能をbindするのではなく機構として特別な設定を施した実装（スミマセン語彙貧弱で意味不明かも）みたいなものは無いのかと。

Cで言ったらiはintでループ専用みたいな割り振りされているのがキモチワルイというか。（そんな事ないけど→ｃ）

>>64
ぱっと分かるだけでもSelf, Io, NewtonScriptがそうだよ。

＞ 特定の名前スロットを特殊な使い方(_PROTO_とか）

_が頭についてんだからシステム予約なのはあたりまえだろヴォケ

「頭に _ は予約」が常識かどうかは知らないけど

>>66
C++ の this ポインタとかもそうかと。必要悪。

schemeみたいにletとかlambdaさえ意味が変わってほっしー☆のかてめえは

>>70
特定のスロットやら変数やらを特別視するってのは、結構言語仕様上気持ち悪いもんだよ
使い勝手を優先するとそうなる場合も多いんだけど

>>63
最新仕様では無事使用禁止だから大丈夫

schemeのアレはコンパイラ作るときに困る

>>67
SELFは任意のスロット名が使えるから違う。

>>73
アレって何？

予約語がないことだろ

defineとかlambdaとかって予約語じゃないの？

lambda は (コンパイル時に他の識別詞と区別されるような) 予約語ではなくて、スペシャルフォームという
define は普通にシステム定義関数で作れたような希ガス

つまり(let ((define 〜))〜とか
(lambda(lambda)〜
とかできるわけですか！

さらに
(define lambda list)
(define if append)
(define-syntax define (syntax-rules () ((_ x) 'x)))
(if (lambda 1 2 3) (define 4))
--> (1 2 3 . 4)
もオケ〜イ

うあｗ、それ困るわｗ

なんで？
人間が読むんじゃなくてコンパイラだろ？
そんなのCのプロプロセッサにスコープがついただけじゃん？

↑真性の馬鹿

よく分かんないけどクラスベース言語のthisとかsuperとかself
とかも気持悪いってことか。ないと困ると思うけどな。

話を蒸し返す様だが、当然それらを自分で変更可能な言語もある

>>81
今Schemeの処理系作ってるけどそんなに困らないぞ。

>>83
真性のバカ。
実際この仕様でいろんな実装でコンパイルできてるのに、何を言ってんだろ。

SELF とか SCHEME とかせいぜいがんばってくれ。
RUBY 並に普及するのは不可能だろうけどね (w

>>88
ヒント：JavaScript (ECMAScript)

つかscheme自体はOOじゃねぇし。アフォか。

アフォはてめーだよ。マイナー言語厨が。マイナーな技術を選ぶ事が
目的になってんじゃねーのか。JavaScript が今後もプロトタイプベース
一本でいくと思ってるの？

つかプロトタイプベースの OO にあって Ruby にない利点があるのかよ (w

Scheme はついでだ。ユーザビリティが低いから氏ね。

おやまあ、、、

Ruby が使いやすいのなら、それを使えば良いじゃない。
俺はマゾだから茨の道を行くよ。

整理すると、
* プロトタイプベースには Ruby と比較するとメリットはない
* マゾには嬉しいらしい
ということか。なんだつまらん。

よくできました

ええいいちいち反応するな

RubyもJS2.0もなかなかブラウザに搭載されませんねー。

そうだね

self の良い書籍ってない？

書籍自体無いんじゃないかな。リサーチプロジェクトだし。

終了

ばいばい

>>98
どんなことが知りたいの？

Perlもプロトタイプベースみたいなことできるじゃん。
もうPerlでいいよ。

ttp://jp.rubyist.net/magazine/?0010-Legwork

↑ってお金もらえてるの？

誰が払うねん

ttp://mput.dip.jp/mput/?date=20051015#p11

Q PragProg の Language of the year で Ruby を学んで以来 Ruby を使い続けている。
あなたが同様に私たちに何か言語を薦めるとすれば何?

A Io かな。シンプルだし興味深い


Q さっき Io に触れましたね?
Ruby をもっとプロトタイプベースに近い形にしたりはしないのですか?

A いや。 Ruby のゴールは単純さではないから。たしかにプロトタイプベースは
仕組みとしてシンプルでよいと思うが、我々が処理の内容をプログラムに書
き下すときには、やはりクラスベースのほうが分かりやすいと思うんだ。
Ruby はそういう側面のほうに注力しているので、クラスベースをやめるつもりはない

>>107 関連
ttp://groups.yahoo.com/group/iolanguage/message/7156

http://d.hatena.ne.jp/epcg/
Io情報ならこのblogでいろいろ得られます。
感謝。

>>109
Ioもそうだが、このスレの主題のプロトタイプベース言語って言語というよりライブラリ側の特性が
言語の表層として現れるおもしろい言語なんだね。
というのはSelf,Io,NewtonScriptの３つしか比べてないのだけど核となる部分はスロットへのメッセージ転送だけであって
あとはスロットに何がつっこまれたかと言う部分の違いの方が遙かに性格の違いを表してるって感じたからなのだけどね。

クラスベースの言語だとそのシンタックスに性格が最初に現れるのとは対照的だね。

クラスを（狭義の）言語仕様からライブラリに追い出しただけ…という話ではなく？

君らそんなことよりクソ遅いメソッドディスパッチ何とかしたほうがいいよ

ごめん、質問。

CLOSについて以下のページにこんなことが書いてあって、
http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview21.html
| もうひとつ、CLOS の機能なんですけど、インスタンスのクラスを実行中に
| 変えられるんですね。クラスの再定義が出来まして、古いクラスから新しい
| クラスへの変換メソッドを書いといてやると、そのインスタンスがアクセス
| された時に、その変換メソッドが走って、インスタンスが update されるんです。

すげえなあ、と思ったんだけど、こういうことはプロトタイプベース名言語
(たとえばJavaScript)なら当たり前にできるもんなの?
プロトタイプベースの言語で、存在しないスロットにアクセスしたときは、
親のスロット見に行くだけで、そこで任意の処理を動かしたりとかはできないよね?

CLOS 知らないんで間違ってるかもしれないけど、例えば Io だと、
存在しないスロットにアクセスしたときには forward という名前のスロットに制御が行くようになってる。

……こういう話？

>>113
ちゃんとしたプロトタイプベースな言語であれば普通にできる。

>>114
了解です。forwardでそのオブジェクトに足りないスロットを追加したり
すればいいわけですね。

http://f21.aaa.livedoor.jp/~kizz/prog/io/_docs/IoProgrammingGuide_ja.html
| オブジェクトがメッセージに応答しないとき、そのオブジェクトが
| "forward" メソッドを持っていれば、それが呼び出される。
| 送られてくるメッセージの名前やその引数は、"thisMessage" スロットに
| 入っている Message オブジェクトから取得できる。そして parent の
| チェインの中で応答するものがあれば、そのオブジェクトにメッセージを
| 送る。

「そして」以降がよくわからんなあ。forwardが呼ばれたあとで常にparentを
呼ぶってこと?
…なんかここだけ原文ついてないし。

>>113
クラスの変換用の Generic Function があって，それを使って変換できる話だ
な。update-instance-for-redefined-class メソッドが起動されるのな。はじ
めてでくわした時ははビビったもんだ…なにやってんの移植性最悪だー!! とお
もったら ANSI 規格の範囲内だった。でもこれも change-class とかもメンテ
ナンス用途以外ではでくわした事ないなー普通にネットででくわすサンプルだ
と出合わないかもね

>>116
＞forwardが呼ばれたあとで常にparentを呼ぶってこと?
ん〜。proto にも parent にもスロットが無ければ forward が呼ばれるみたい。
ただ単に文の順序が逆なだけじゃないのか？

新しいIoからはparent無くなるんじゃなかったっけ？
又聞きだからホントか解らんけど……

>>118
>ん〜。proto にも parent にもスロットが無ければ forward が呼ばれるみたい。

よくわかった。ありがとう。

原文はここらしいんだけど、
http://www.iolanguage.com/rsync/release/Io/_docs/guide.html

該当する文はやっぱり存在しない…

>>119
もうない。

>>119
ごめん。持ってた VM のバージョンが古かったみたい。

で、プロトタイプベースのメリットって何よ。

ぶっちゃけ言うと 『単純さ』

単純さって、処理系作る奴のメリットじゃね？
処理系使う側のメリットはなしか？
ちなみに、単純＝学習コストが低いとはいえないだろ。
たとえば、言語として超単純なLispが特に低いとは思えない。

lisp が単純なのは構文だけだよ

クラスやらなんやらを全部取っ払って、どんどん単純にしてったものがプロトタイプベース
構文だけじゃなくて、概念的に単純なんだな

まあ確かに、単純＝学習コストが低いとはいえないから、この単純さはメリットでもありデメリットでもあるけど。

プロトタイプベースのほうが、具体的にこういうことをしたいときに楽だ、
という例があれば俺も知りたい。
プロトタイプベースの俺言語作ってるんだけど、メリットが自分で説明できん w

むしろ、C++みたいな静的なOOPLならともかく、Rubyみたいな動的なOOPLでクラスが存在する意義ってなんだろ？

↓性懲りもなくCoRの例を出すやつ。それはOOなのか？そいつらはis-aなのか？つうかそれだけかよ。

プロトタイプベースのメリット　単純なので、俺言語とか作りやすい。

>>128
OOとしてモデリングが自然。
種類A　is-a 種類B　が普通。
実体A　is-a 実体B　なんてありえん。

犬 is-a 哺乳類 OK
ポチ is-a タマ NG

あ、今更だが POO にはモデリングが無いことに気付いた。モデリング無しで直接オブジェクト作ってるやん。

>>128
「型」の提供なんだろうなぁ

クラス宣言して、メソッド書いて、使うときにはインスタンス作ってという流れの
基本的な型があって、そういう型を組み合わせていけば複雑なこともできる。

今の主流でもあるから多くの人にも理解しやすい・使いやすい。
意義は分からないけどメリットは大きい。

>>130
確かに高速化とか考えなければ処理系作るの若干楽だけど、
処理系作りやすいってのをメリットと言われてもなあ。
処理系だけ作って使われない言語じゃ存在意義ないし。

『処理系が小さい＆記述が簡単』 なら組み込み系に有利かと思った。

結論
　処理系使う側のメリットは茄子

>>135
CPUパワーもメモリも売るほどあるなら処理系作るのは楽だが、
組み込みではかえって苦労するんでは。

ソニーがFSKなんかそうじゃね。実際もっさり？
あと普通のアプリのマクロとか。

>>133
逆に、「型」なんて余計なものを考えなくていい、ってのがプロトタイプベースのメリットなのかな。
必要なときに最低限の記述をすれば動くっていう、スクリプト言語みたいな。

>>133が逝ってる「型」は、Typeではなく、武道の「型」とか紋切り「型」の類。
だから、考えなくていいのは、「型」があるほう。

>>133
「型」は「流れ」とでも翻訳した方が良さそげだね。

>>140
そっか、誤読。
定型の作業なら、確かに慣れれば意識しなくなりそうだね。

そうすると、プロトタイプベース側は…もっとすっきり書ける、とかかな。
大規模で複雑怪奇になると結局 traits みたいなのが欲しくなるけど、そうじゃないときも多いし。
とりあえず動かしたいものがあるときに、手早く仕上げられるっていうか。

このパラダイムに未来はないな

>>143
中身が無いんで、何故未来が無いのかを書いて欲しいんだが。

>>144
AJAXスレから流れてきた池沼だよ。
スルーしる。

>>145
がっかりだよね。

コンパイラ使うんならクラスベースで
インタプリタ系ならプロトタイプベースのが向くでFAじゃね？

JavaScriptって厳密に言えばプロトタイプベースじゃないよね？

プロトタイプベースの定義を適用すると当てはまると思うんだが、何がイカンと思うわけ？>>148

clone じゃなくてコンストラクタでオブジェクトを作るから？
オブジェクト自体のprototypeを自由に出来ないから、とか？
クラス、とか新しく入ってきたから、とか？

>>150
JavaScript2.0のことは知らないけど、上の２行についてはそんな感じ。

"The Power of Simplicity"　の　Powerってどんな力？

シンプルな脳みそのやつを怒らすと怖いってことだろ。

>>152
継続は力なり、の力と同じような力

Emacsのio-mode発見しますた。
とりあえずカラフルになった。

ttp://www.alcyone.com/software/io-mode/io-mode.el

プロトタイプ指向を簡単に実装できそうな既存の言語って何だろ。

>>156
Lisp

>>154
積もった塵ですか

>>156
GC があって、構文を弄る仕組み（マクロとか）がある言語だと楽そうね。
Dylan とか。

>>156
FORTH

これぞプロトタイプベース！っていうコードってどんなの？
ベタなChain of responsibility以外で。

>>161
根底のObjectに後から何かつっこんで全部の階層から使えるとか（ｗ

それって、クラスベースでも動的言語ならObjectクラスにあとから追加とか出来るじゃん。

ただ、ネームスペースがしっかりてない言語でこれは勘弁して欲しい。
メンバを舐めてる処理が突如おかしくなるｗ

>>163
JavaScriptで良くあるんだよね orz

>>162
静的言語でも極一部(MixJuiceやDelphiや字面上だけならC#3.0も)はできるぞ

（内部的にも）新規にクラスを作ったり、そうしたものを介したりせずに…という
“しばり”を設けたら、どうよ…。

縛る意味が分からない。マニアの方ですか？

あえて縛りを設けることで、頭の弱い奴が同一視するものとの違いを際だたせる
ことができるってことだろ。まあ、そんな程度じゃ馬鹿の壁は越えられんのだが。

と、バカが申しておりますが、どないしますか？

たしかにクラスの助けを借りずにインスタンスが独自のスロットを持てるのは
いっけん効率いいようにおもえるけど、そもそもベーサルで効率悪いシステムだから
なぁ…。びみょー。

　

プロトタイプ言語って、メソッドはプロトタイプ毎に保持しているんだよね?

>>172
そういうこともするが、それだけとは限らない。

他のプロトタイプに委譲することも多いよね。

つか、自分で持つか委譲しかないんだが…。

・共有する
・コピーする
つうのもあるよ。

>>176
共有する … 委譲
コピーする … 自分で持つ

共有する->所有権あり
委譲する->所有権なし

コピーする->オリジナルが存在
自分でもつ->オリジナルの有無は不明

つう感じかね。

いずれにせよ、委譲するか、その必要がないかに帰着できる。

だからそれだけじゃ足りないんだって。
委譲するかどうかだけではリソースの扱いを決定できないんだって。

委譲しない（＝自分が所有権を持つ）としても、もし他と共有するとなるとそのリソース
（メソッド）を勝手に加工できないから、それなりの扱いが必要でしょ

コピーするかどうかは、初期化の場面しか関係しないけどな。

それは小手先に過ぎなくて、なんというか本質から外れているような。

ああ。なんか分かってきたぞ。

176は、継承（あるいはインスタンス化、もしくはクローン化）の様式を整理したいのか。
それならコピーがどうのこうのってのも分かる。
たしかに、委譲の他に、手続きを共有する方法と、コピーを持ってしまう方法がある。

まあ、172がそもそも何を聞きたいのかわからんというのが問題なのだが…。
「プロトタイプ毎」というのはおかしいから「プロトタイプ（ベースの）言語」のプロトタイプに
引っ張られて「オブジェクト毎」とするところを書き（あるいは理解し）間違えたと解釈して、

「オブジェクト毎にメソッドを持つかどうか」

と問われているとすれば、そういうこともあるし他者に委譲することもある、と答えるし、そうではなく、

「クローン（多くの場合チャイルド）はプロトタイプ（多くの場合ペアレント）にメソッドを持たせるのか」

と問うているのならば、それ、つまり、委譲機構以外にも自前でコピーで持ったり（クローン、コピー）、
プロトタイプと共有する（シャローコピー）のこともある、という176のような答になる。

スンマせん。過疎スレだったので、ちゃんと整理せずに軽い気持ちで書き込みますた。

プロトタイプ言語のインタープリタを作る時に、メソッドの一覧は何処に持たせるのが
良いのかなというのが最初の疑問です。

何処に?
・グローバルに 1 つ
・メソッド名毎に 1 つ（ジェネリックな感じで）
・オブジェクト毎（プロトタイプもオブジェクトに含む）

どういう形式で?
・リスト
・ハッシュ

クラスベースな言語なら、クラス毎にハッシュでメソッドリストを持たせてもそんなに
オーバーヘッドな感じはしないですが、プロトタイプ言語でオブジェクト毎にハッシュを
持たせたら、個々のオブジェクトのサイズが大変な事になりそうで。

今考えているのは、オブジェクト毎にメソッドのリストを持たせて、グローバルにハッシュで
キャッシュを持つ感じです。io なり javascript なりの実装を調べてみます。

>>183
最初からそう言えや (´･ω･`)

例えば io はオブジェクト毎にハッシュテーブルを１つ持ってる。
他は知らないけど。


ちなみに 『プロトタイプもオブジェクトに含む』 みたいな文が出てくる時点で、
あまりプロトタイプベースについて詳しくないんじゃないかなとか予想してたり。

>>184
重ね重ねｽﾐﾏｾﾝ。

プロトタイプは、単に他のオブジェクトのプロトタイプスロットから参照されているだけで、
実態は普通のオブジェクトだと思ってました。

//　継承前
function Person(nAge) {
this.m_nAge = nAge;
}

Person.prototype.getAge = function() {
return this.m_nAge;
};

// 継承先
function Programmer(nAge, strProject) {
this.__super = Person; // 新インスタンスを介して
this.__super(nAge); // 継承元コンストラクタを呼ぶ
this.constructor = Programmer; // コンストラクタが Person にセットされるので元に戻す
delete this.__super;
/* Programmer コンストラクタの処理 */
}

// 継承先の方法2つ目
function Programmer(nAge, strProject) {
Person.call(this, nAge);
this.constructor = Programmer;
/* Programmer コンストラクタの処理 */
}
このコードでＰｅｒｓｏｎのプロパティをＰｒｏｇｒａｍｍｅｒのプロパティで継承する際に、
Person(nAge)として、親のコンストラクタを呼んで
値を初期化せずに、スコープを変更して呼びしているのは、
そうしないと、値へのアクセスがインスタンスを介して出来なくなるからですか？
いまひとつ変数のスコープが理解できません。
Personクラスのthis.m_nAge = nAge;を呼び出しても、
インスタンスがthisに入るので、インスタンスの変数としてm_nAgeが初期化され
そうに思えてしまいます。

　

>>186
this には、その関数を起動する際の第一オペランド(ドット演算子の前にあるオブジェクト)が束縛されています。
メッセージングメタファで言えば、メッセージの受け手であるレシーバですね。（どちらでも、お好きな方で）

new Programmer(21, "EJS"); で起動された Programmer 内において、this には、新しく作られたインスタンス
（ここでは仮に this_prog と呼称することにします）が束縛されています。その場で this.__super(nAge); により
起動、つまり、this_prog.__super(nAge) で起動された Person 内では、this は this_prog を束縛することになります。

ですから、Person 内の this.m_nAge = nAge; は、つまり this_prog.m_nAge への nAge の束縛ということに
なるので、戻ってくると新しく作ったインスタンスの m_nAge スロットには 21 が束縛されている…というカラクリです。

もし、__super スロットを介さずに、ただ Person を起動しただけでは、第一オペランドが省略時のグローバル
オブジェクト [object global] になってしまうので、Person 内の this もそうなってしまい、m_nAge スロットも
グローバルオブジェクトに作られてしまいます。

>>188
なるほど、そういう風に規定されているのですね。
勉強不足ですいません・・・ありがとうございます

>>612
//　継承前
function Person(nAge) {
this.m_nAge = nAge;
}

Person.prototype.getAge = function() {
return this.m_nAge;
};

// 継承先
function Programmer(nAge, strProject) {
this.__super = Person; // 新インスタンスを介して
this.__super(nAge); // 継承元コンストラクタを呼ぶ
this.constructor = Programmer; // コンストラクタが Person にセットされるので元に戻す
delete this.__super;
/* Programmer コンストラクタの処理 */
}

// 継承先の方法2つ目
function Programmer(nAge, strProject) {
Person.call(this, nAge);
this.constructor = Programmer;
/* Programmer コンストラクタの処理 */
}

まあ、これなんだけどね。
Person.call(this, nAge);
ここが何でこうなるんだろうと凄く不思議に思った。
prototype.jsはどうやってクラスみたいな仕組みを実装してるんだろうか。

すいません・・・誤爆しました。。
きにしないでください

prototypeのAjax.UpdaterってFireFoxで動かない？
evalScripts:trueで使いたいんだけど、どうも動かない。既出？

>>192
板違い。こっち池。
+ JavaScript の質問用スレッド vol.51 +
http://pc8.2ch.net/test/read.cgi/hp/1158468856/

>>193
あああ・・・そっちもスレ違いなので変なの誘導しないで・・・

JavaScriptは大流行りなのに、こっちは寂れてしまったな

>>195
でもその話しちゃうと現場での愚痴大会になっちゃうからなぁ。

寂れてもチェックは欠かさない

JavaScriptでもプロトタイプ継承をバリバリ使ってるやつは例外中の例外だろ

冬休み中にself似の言語にnative型の概念入れようと努力したけどﾑﾘﾎﾟ