05/09/17 20:35:16
>>73
アレって何？
76:デフォルトの名無しさん
05/09/17 21:09:16
予約語がないことだろ
77:デフォルトの名無しさん
05/09/19 22:20:49
defineとかlambdaとかって予約語じゃないの？
78:デフォルトの名無しさん
05/09/19 23:27:50
lambda は (コンパイル時に他の識別詞と区別されるような) 予約語ではなくて、スペシャルフォームという
define は普通にシステム定義関数で作れたような希ガス
79:デフォルトの名無しさん
05/09/23 06:02:48
つまり(let ((define ～))～とか
(lambda(lambda)～
とかできるわけですか！
80:デフォルトの名無しさん
05/09/23 06:51:23
さらに
(define lambda list)
(define if append)
(define-syntax define (syntax-rules () ((_ x) 'x)))
(if (lambda 1 2 3) (define 4))
--> (1 2 3 . 4)
もオケ～イ
81:デフォルトの名無しさん
05/09/23 06:58:14
うあｗ、それ困るわｗ
82:デフォルトの名無しさん
05/10/02 03:45:23
なんで？
人間が読むんじゃなくてコンパイラだろ？
そんなのCのプロプロセッサにスコープがついただけじゃん？
83:デフォルトの名無しさん
05/10/02 03:52:38
↑真性の馬鹿
84:デフォルトの名無しさん
05/10/02 08:00:19
よく分かんないけどクラスベース言語のthisとかsuperとかself
とかも気持悪いってことか。ないと困ると思うけどな。
85:デフォルトの名無しさん
05/10/02 08:16:07
話を蒸し返す様だが、当然それらを自分で変更可能な言語もある
86:デフォルトの名無しさん
05/10/02 15:23:49
>>81
今Schemeの処理系作ってるけどそんなに困らないぞ。
87:デフォルトの名無しさん
05/10/02 16:08:44
>>83
真性のバカ。
実際この仕様でいろんな実装でコンパイルできてるのに、何を言ってんだろ。
88:デフォルトの名無しさん
05/10/02 17:08:06
SELF とか SCHEME とかせいぜいがんばってくれ。
RUBY 並に普及するのは不可能だろうけどね (w
89:デフォルトの名無しさん
05/10/02 18:01:02
>>88
ヒント：JavaScript (ECMAScript)
つかscheme自体はOOじゃねぇし。アフォか。
90:デフォルトの名無しさん
05/10/03 01:53:14
アフォはてめーだよ。マイナー言語厨が。マイナーな技術を選ぶ事が
目的になってんじゃねーのか。JavaScript が今後もプロトタイプベース
一本でいくと思ってるの？
つかプロトタイプベースの OO にあって Ruby にない利点があるのかよ (w
Scheme はついでだ。ユーザビリティが低いから氏ね。
91:デフォルトの名無しさん
05/10/03 01:55:15
おやまあ、、、
92:デフォルトの名無しさん
05/10/03 01:55:29
Ruby が使いやすいのなら、それを使えば良いじゃない。
俺はマゾだから茨の道を行くよ。
93:デフォルトの名無しさん
05/10/03 02:17:18
整理すると、
* プロトタイプベースには Ruby と比較するとメリットはない
* マゾには嬉しいらしい
ということか。なんだつまらん。
94:デフォルトの名無しさん
05/10/03 02:18:26
よくできました
95:デフォルトの名無しさん
05/10/03 02:58:49
ええいいちいち反応するな
96:デフォルトの名無しさん
05/10/04 08:18:47
RubyもJS2.0もなかなかブラウザに搭載されませんねー。
97:デフォルトの名無しさん
05/10/05 01:53:12
そうだね
98:デフォルトの名無しさん
05/10/05 02:23:54
self の良い書籍ってない？
99:デフォルトの名無しさん
05/10/05 06:19:32
書籍自体無いんじゃないかな。リサーチプロジェクトだし。
100:デフォルトの名無しさん
05/10/06 07:01:47
終了
101:デフォルトの名無しさん
05/10/06 09:07:14
ばいばい
102:デフォルトの名無しさん
05/10/07 22:59:14
>>98
どんなことが知りたいの？
103:デフォルトの名無しさん
05/10/10 17:23:57
Perlもプロトタイプベースみたいなことできるじゃん。
もうPerlでいいよ。
104:デフォルトの名無しさん
05/10/13 02:38:40
URLﾘﾝｸ(jp.rubyist.net)
105:デフォルトの名無しさん
05/10/13 20:49:45
↑ってお金もらえてるの？
106:デフォルトの名無しさん
05/10/16 00:55:08
誰が払うねん
107:デフォルトの名無しさん
05/10/16 09:35:33
URLﾘﾝｸ(mput.dip.jp)
Q PragProg の Language of the year で Ruby を学んで以来 Ruby を使い続けている。
あなたが同様に私たちに何か言語を薦めるとすれば何?
A Io かな。シンプルだし興味深い
Q さっき Io に触れましたね?
Ruby をもっとプロトタイプベースに近い形にしたりはしないのですか?
A いや。 Ruby のゴールは単純さではないから。たしかにプロトタイプベースは
仕組みとしてシンプルでよいと思うが、我々が処理の内容をプログラムに書
き下すときには、やはりクラスベースのほうが分かりやすいと思うんだ。
Ruby はそういう側面のほうに注力しているので、クラスベースをやめるつもりはない
108:デフォルトの名無しさん
05/10/16 10:40:55
>>107 関連
URLﾘﾝｸ(groups.yahoo.com)
109:デフォルトの名無しさん
05/10/17 23:16:07
URLﾘﾝｸ(d.hatena.ne.jp)
Io情報ならこのblogでいろいろ得られます。
感謝。
110:デフォルトの名無しさん
05/10/18 02:59:22
>>109
Ioもそうだが、このスレの主題のプロトタイプベース言語って言語というよりライブラリ側の特性が
言語の表層として現れるおもしろい言語なんだね。
というのはSelf,Io,NewtonScriptの３つしか比べてないのだけど核となる部分はスロットへのメッセージ転送だけであって
あとはスロットに何がつっこまれたかと言う部分の違いの方が遙かに性格の違いを表してるって感じたからなのだけどね。
クラスベースの言語だとそのシンタックスに性格が最初に現れるのとは対照的だね。
111:デフォルトの名無しさん
05/10/18 12:01:15
クラスを（狭義の）言語仕様からライブラリに追い出しただけ…という話ではなく？
112:デフォルトの名無しさん
05/11/03 15:01:00
君らそんなことよりクソ遅いメソッドディスパッチ何とかしたほうがいいよ
113:デフォルトの名無しさん
05/11/06 00:51:10
ごめん、質問。
CLOSについて以下のページにこんなことが書いてあって、
URLﾘﾝｸ(www.ogis-ri.co.jp)
| もうひとつ、CLOS の機能なんですけど、インスタンスのクラスを実行中に
| 変えられるんですね。クラスの再定義が出来まして、古いクラスから新しい
| クラスへの変換メソッドを書いといてやると、そのインスタンスがアクセス
| された時に、その変換メソッドが走って、インスタンスが update されるんです。
すげえなあ、と思ったんだけど、こういうことはプロトタイプベース名言語
(たとえばJavaScript)なら当たり前にできるもんなの?
プロトタイプベースの言語で、存在しないスロットにアクセスしたときは、
親のスロット見に行くだけで、そこで任意の処理を動かしたりとかはできないよね?
114:デフォルトの名無しさん
05/11/06 01:06:43
CLOS 知らないんで間違ってるかもしれないけど、例えば Io だと、
存在しないスロットにアクセスしたときには forward という名前のスロットに制御が行くようになってる。
……こういう話？
115:デフォルトの名無しさん
05/11/06 01:52:23
>>113
ちゃんとしたプロトタイプベースな言語であれば普通にできる。
116:113
05/11/06 02:47:22
>>114
了解です。forwardでそのオブジェクトに足りないスロットを追加したり
すればいいわけですね。
URLﾘﾝｸ(f21.aaa.livedoor.jp)
| オブジェクトがメッセージに応答しないとき、そのオブジェクトが
| "forward" メソッドを持っていれば、それが呼び出される。
| 送られてくるメッセージの名前やその引数は、"thisMessage" スロットに
| 入っている Message オブジェクトから取得できる。そして parent の
| チェインの中で応答するものがあれば、そのオブジェクトにメッセージを
| 送る。
「そして」以降がよくわからんなあ。forwardが呼ばれたあとで常にparentを
呼ぶってこと?
…なんかここだけ原文ついてないし。
117:デフォルトの名無しさん
05/11/06 10:45:22
>>113
クラスの変換用の Generic Function があって，それを使って変換できる話だ
な。update-instance-for-redefined-class メソッドが起動されるのな。はじ
めてでくわした時ははビビったもんだ…なにやってんの移植性最悪だー!! とお
もったら ANSI 規格の範囲内だった。でもこれも change-class とかもメンテ
ナンス用途以外ではでくわした事ないなー普通にネットででくわすサンプルだ
と出合わないかもね
118:デフォルトの名無しさん
05/11/06 10:58:02
>>116
＞forwardが呼ばれたあとで常にparentを呼ぶってこと?
ん～。proto にも parent にもスロットが無ければ forward が呼ばれるみたい。
ただ単に文の順序が逆なだけじゃないのか？
119:デフォルトの名無しさん
05/11/06 13:46:17
新しいIoからはparent無くなるんじゃなかったっけ？
又聞きだからホントか解らんけど……
120:113
05/11/06 14:16:37
>>118
>ん～。proto にも parent にもスロットが無ければ forward が呼ばれるみたい。
よくわかった。ありがとう。
原文はここらしいんだけど、
URLﾘﾝｸ(www.iolanguage.com)
該当する文はやっぱり存在しない…
121:デフォルトの名無しさん
05/11/06 14:43:22
>>119
もうない。
122:118
05/11/06 18:23:02
>>119
ごめん。持ってた VM のバージョンが古かったみたい。
123:デフォルトの名無しさん
05/11/23 15:26:47
で、プロトタイプベースのメリットって何よ。
124:デフォルトの名無しさん
05/11/23 18:25:56
ぶっちゃけ言うと 『単純さ』
125:デフォルトの名無しさん
05/11/23 21:44:53
単純さって、処理系作る奴のメリットじゃね？
処理系使う側のメリットはなしか？
ちなみに、単純＝学習コストが低いとはいえないだろ。
たとえば、言語として超単純なLispが特に低いとは思えない。
126:デフォルトの名無しさん
05/11/23 21:55:44
lisp が単純なのは構文だけだよ
クラスやらなんやらを全部取っ払って、どんどん単純にしてったものがプロトタイプベース
構文だけじゃなくて、概念的に単純なんだな
まあ確かに、単純＝学習コストが低いとはいえないから、この単純さはメリットでもありデメリットでもあるけど。
127:デフォルトの名無しさん
05/11/23 23:28:23
プロトタイプベースのほうが、具体的にこういうことをしたいときに楽だ、
という例があれば俺も知りたい。
プロトタイプベースの俺言語作ってるんだけど、メリットが自分で説明できん w
128:デフォルトの名無しさん
05/11/23 23:47:01
むしろ、C++みたいな静的なOOPLならともかく、Rubyみたいな動的なOOPLでクラスが存在する意義ってなんだろ？
129:デフォルトの名無しさん
05/11/23 23:48:11
↓性懲りもなくCoRの例を出すやつ。それはOOなのか？そいつらはis-aなのか？つうかそれだけかよ。
130:デフォルトの名無しさん
05/11/23 23:48:27
プロトタイプベースのメリット 単純なので、俺言語とか作りやすい。
131:デフォルトの名無しさん
05/11/23 23:52:51
>>128
OOとしてモデリングが自然。
種類A is-a 種類B が普通。
実体A is-a 実体B なんてありえん。
犬 is-a 哺乳類 OK
ポチ is-a タマ NG
132:デフォルトの名無しさん
05/11/23 23:56:45
あ、今更だが POO にはモデリングが無いことに気付いた。モデリング無しで直接オブジェクト作ってるやん。
133:デフォルトの名無しさん
05/11/24 00:01:57
>>128
「型」の提供なんだろうなぁ
クラス宣言して、メソッド書いて、使うときにはインスタンス作ってという流れの
基本的な型があって、そういう型を組み合わせていけば複雑なこともできる。
今の主流でもあるから多くの人にも理解しやすい・使いやすい。
意義は分からないけどメリットは大きい。
134:デフォルトの名無しさん
05/11/24 01:10:57
>>130
確かに高速化とか考えなければ処理系作るの若干楽だけど、
処理系作りやすいってのをメリットと言われてもなあ。
処理系だけ作って使われない言語じゃ存在意義ないし。
135:デフォルトの名無しさん
05/11/24 01:17:20
『処理系が小さい＆記述が簡単』 なら組み込み系に有利かと思った。
136:デフォルトの名無しさん
05/11/24 01:22:17
結論
処理系使う側のメリットは茄子
137:デフォルトの名無しさん
05/11/24 01:34:47
>>135
CPUパワーもメモリも売るほどあるなら処理系作るのは楽だが、
組み込みではかえって苦労するんでは。
138:デフォルトの名無しさん
05/11/24 01:37:05
ソニーがFSKなんかそうじゃね。実際もっさり？
あと普通のアプリのマクロとか。
139:デフォルトの名無しさん
05/11/24 05:46:51
>>133
逆に、「型」なんて余計なものを考えなくていい、ってのがプロトタイプベースのメリットなのかな。
必要なときに最低限の記述をすれば動くっていう、スクリプト言語みたいな。
140:デフォルトの名無しさん
05/11/24 10:57:41
>>133が逝ってる「型」は、Typeではなく、武道の「型」とか紋切り「型」の類。
だから、考えなくていいのは、「型」があるほう。
141:デフォルトの名無しさん
05/11/24 11:43:46
>>133
「型」は「流れ」とでも翻訳した方が良さそげだね。
142:デフォルトの名無しさん
05/11/24 18:29:44
>>140
そっか、誤読。
定型の作業なら、確かに慣れれば意識しなくなりそうだね。
そうすると、プロトタイプベース側は…もっとすっきり書ける、とかかな。
大規模で複雑怪奇になると結局 traits みたいなのが欲しくなるけど、そうじゃないときも多いし。
とりあえず動かしたいものがあるときに、手早く仕上げられるっていうか。
143:デフォルトの名無しさん
05/11/26 03:11:55
このパラダイムに未来はないな
144:デフォルトの名無しさん
05/11/26 10:18:46
>>143
中身が無いんで、何故未来が無いのかを書いて欲しいんだが。
145:デフォルトの名無しさん
05/11/26 14:13:27
>>144
AJAXスレから流れてきた池沼だよ。
スルーしる。
146:デフォルトの名無しさん
05/11/26 17:18:13
>>145
がっかりだよね。
147:デフォルトの名無しさん
05/11/28 17:20:57
コンパイラ使うんならクラスベースで
インタプリタ系ならプロトタイプベースのが向くでFAじゃね？
148:デフォルトの名無しさん
05/11/29 21:14:50
JavaScriptって厳密に言えばプロトタイプベースじゃないよね？
149:デフォルトの名無しさん
05/11/29 21:39:27
プロトタイプベースの定義を適用すると当てはまると思うんだが、何がイカンと思うわけ？>>148
150:デフォルトの名無しさん
05/11/30 01:20:54
clone じゃなくてコンストラクタでオブジェクトを作るから？
オブジェクト自体のprototypeを自由に出来ないから、とか？
クラス、とか新しく入ってきたから、とか？
151:148
05/12/07 22:40:09
>>150
JavaScript2.0のことは知らないけど、上の２行についてはそんな感じ。
152:デフォルトの名無しさん
05/12/08 00:43:51
"The Power of Simplicity" の Powerってどんな力？
153:デフォルトの名無しさん
05/12/19 18:14:06
シンプルな脳みそのやつを怒らすと怖いってことだろ。
154:デフォルトの名無しさん
05/12/20 09:35:11
>>152
継続は力なり、の力と同じような力
155:デフォルトの名無しさん
05/12/20 12:08:42
Emacsのio-mode発見しますた。
とりあえずカラフルになった。
URLﾘﾝｸ(www.alcyone.com)
156:デフォルトの名無しさん
06/01/26 01:36:33
プロトタイプ指向を簡単に実装できそうな既存の言語って何だろ。
157:デフォルトの名無しさん
06/01/26 01:50:38
>>156
Lisp
158:デフォルトの名無しさん
06/01/26 02:17:10
>>154
積もった塵ですか
159:デフォルトの名無しさん
06/01/26 02:20:32
>>156
GC があって、構文を弄る仕組み（マクロとか）がある言語だと楽そうね。
Dylan とか。
160:デフォルトの名無しさん
06/01/26 09:06:21
>>156
FORTH
161:デフォルトの名無しさん
06/03/02 02:47:21
これぞプロトタイプベース！っていうコードってどんなの？
ベタなChain of responsibility以外で。
162:デフォルトの名無しさん
06/03/02 09:51:04
>>161
根底のObjectに後から何かつっこんで全部の階層から使えるとか（ｗ
163:デフォルトの名無しさん
06/03/02 10:01:55
それって、クラスベースでも動的言語ならObjectクラスにあとから追加とか出来るじゃん。
ただ、ネームスペースがしっかりてない言語でこれは勘弁して欲しい。
メンバを舐めてる処理が突如おかしくなるｗ
164:デフォルトの名無しさん
06/03/02 10:11:34
>>163
JavaScriptで良くあるんだよね orz
165:デフォルトの名無しさん
06/03/03 00:54:28
>>162
静的言語でも極一部(MixJuiceやDelphiや字面上だけならC#3.0も)はできるぞ
166:デフォルトの名無しさん
06/03/03 11:30:15
（内部的にも）新規にクラスを作ったり、そうしたものを介したりせずに…という
“しばり”を設けたら、どうよ…。
167:デフォルトの名無しさん
06/03/03 14:25:52
縛る意味が分からない。マニアの方ですか？
168:デフォルトの名無しさん
06/03/03 23:12:50
あえて縛りを設けることで、頭の弱い奴が同一視するものとの違いを際だたせる
ことができるってことだろ。まあ、そんな程度じゃ馬鹿の壁は越えられんのだが。
169:デフォルトの名無しさん
06/03/03 23:19:22
と、バカが申しておりますが、どないしますか？
170:デフォルトの名無しさん
06/03/05 22:29:01
たしかにクラスの助けを借りずにインスタンスが独自のスロットを持てるのは
いっけん効率いいようにおもえるけど、そもそもベーサルで効率悪いシステムだから
なぁ…。びみょー。
171:デフォルトの名無しさん
06/06/05 00:17:54
172:デフォルトの名無しさん
06/06/10 05:43:29
プロトタイプ言語って、メソッドはプロトタイプ毎に保持しているんだよね?
173:デフォルトの名無しさん
06/06/10 08:41:00
>>172
そういうこともするが、それだけとは限らない。
174:デフォルトの名無しさん
06/06/10 11:02:53
他のプロトタイプに委譲することも多いよね。
175:デフォルトの名無しさん
06/06/10 11:28:24
つか、自分で持つか委譲しかないんだが…。
176:デフォルトの名無しさん
06/06/10 16:44:49
・共有する
・コピーする
つうのもあるよ。
177:デフォルトの名無しさん
06/06/10 20:54:41
>>176
共有する … 委譲
コピーする … 自分で持つ
178:デフォルトの名無しさん
06/06/11 02:00:59
共有する->所有権あり
委譲する->所有権なし
コピーする->オリジナルが存在
自分でもつ->オリジナルの有無は不明
つう感じかね。
179:デフォルトの名無しさん
06/06/11 10:04:42
いずれにせよ、委譲するか、その必要がないかに帰着できる。
180:176
06/06/11 14:37:11
だからそれだけじゃ足りないんだって。
委譲するかどうかだけではリソースの扱いを決定できないんだって。
委譲しない（＝自分が所有権を持つ）としても、もし他と共有するとなるとそのリソース
（メソッド）を勝手に加工できないから、それなりの扱いが必要でしょ
コピーするかどうかは、初期化の場面しか関係しないけどな。
181:デフォルトの名無しさん
06/06/11 18:29:11
それは小手先に過ぎなくて、なんというか本質から外れているような。
182:デフォルトの名無しさん
06/06/11 19:07:05
ああ。なんか分かってきたぞ。
176は、継承（あるいはインスタンス化、もしくはクローン化）の様式を整理したいのか。
それならコピーがどうのこうのってのも分かる。
たしかに、委譲の他に、手続きを共有する方法と、コピーを持ってしまう方法がある。
まあ、172がそもそも何を聞きたいのかわからんというのが問題なのだが…。
「プロトタイプ毎」というのはおかしいから「プロトタイプ（ベースの）言語」のプロトタイプに
引っ張られて「オブジェクト毎」とするところを書き（あるいは理解し）間違えたと解釈して、
「オブジェクト毎にメソッドを持つかどうか」
と問われているとすれば、そういうこともあるし他者に委譲することもある、と答えるし、そうではなく、
「クローン（多くの場合チャイルド）はプロトタイプ（多くの場合ペアレント）にメソッドを持たせるのか」
と問うているのならば、それ、つまり、委譲機構以外にも自前でコピーで持ったり（クローン、コピー）、
プロトタイプと共有する（シャローコピー）のこともある、という176のような答になる。
183:172
06/06/11 19:45:16
スンマせん。過疎スレだったので、ちゃんと整理せずに軽い気持ちで書き込みますた。
プロトタイプ言語のインタープリタを作る時に、メソッドの一覧は何処に持たせるのが
良いのかなというのが最初の疑問です。
何処に?
・グローバルに 1 つ
・メソッド名毎に 1 つ（ジェネリックな感じで）
・オブジェクト毎（プロトタイプもオブジェクトに含む）
どういう形式で?
・リスト
・ハッシュ
クラスベースな言語なら、クラス毎にハッシュでメソッドリストを持たせてもそんなに
オーバーヘッドな感じはしないですが、プロトタイプ言語でオブジェクト毎にハッシュを
持たせたら、個々のオブジェクトのサイズが大変な事になりそうで。
今考えているのは、オブジェクト毎にメソッドのリストを持たせて、グローバルにハッシュで
キャッシュを持つ感じです。io なり javascript なりの実装を調べてみます。
184:デフォルトの名無しさん
06/06/11 19:57:27
>>183
最初からそう言えや (´･ω･`)
例えば io はオブジェクト毎にハッシュテーブルを１つ持ってる。
他は知らないけど。
ちなみに 『プロトタイプもオブジェクトに含む』 みたいな文が出てくる時点で、
あまりプロトタイプベースについて詳しくないんじゃないかなとか予想してたり。
185:172
06/06/11 20:14:36
>>184
重ね重ねｽﾐﾏｾﾝ。
プロトタイプは、単に他のオブジェクトのプロトタイプスロットから参照されているだけで、
実態は普通のオブジェクトだと思ってました。
186:更紗 ◆SARAHxmkr.
06/06/15 04:23:03
// 継承前
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が初期化され
そうに思えてしまいます。
187:更紗 ◆SARAHxmkr.
06/06/15 04:24:59
188:デフォルトの名無しさん
06/06/15 15:47:53
>>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 スロットも
グローバルオブジェクトに作られてしまいます。
189:デフォルトの名無しさん
06/06/15 22:53:19
>>188
なるほど、そういう風に規定されているのですね。
勉強不足ですいません・・・ありがとうございます
190:更紗 ◆SARAHxmkr.
06/06/15 23:22:21
>>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はどうやってクラスみたいな仕組みを実装してるんだろうか。
191:更紗 ◆SARAHxmkr.
06/06/15 23:23:16
すいません・・・誤爆しました。。
きにしないでください
192:デフォルトの名無しさん
06/10/09 11:42:23
prototypeのAjax.UpdaterってFireFoxで動かない？
evalScripts:trueで使いたいんだけど、どうも動かない。既出？
193:デフォルトの名無しさん
06/10/09 12:28:20
>>192
板違い。こっち池。
+ JavaScript の質問用スレッド vol.51 +
ｽﾚﾘﾝｸ(hp板)
194:デフォルトの名無しさん
06/10/09 12:34:58
>>193
あああ・・・そっちもスレ違いなので変なの誘導しないで・・・
195:デフォルトの名無しさん
06/12/10 01:29:51
JavaScriptは大流行りなのに、こっちは寂れてしまったな
196:デフォルトの名無しさん
06/12/10 01:39:01
>>195
でもその話しちゃうと現場での愚痴大会になっちゃうからなぁ。
197:デフォルトの名無しさん
06/12/10 01:48:43
寂れてもチェックは欠かさない
198:デフォルトの名無しさん
06/12/10 13:43:52
JavaScriptでもプロトタイプ継承をバリバリ使ってるやつは例外中の例外だろ
199:デフォルトの名無しさん
07/01/04 23:05:10
冬休み中にself似の言語にnative型の概念入れようと努力したけどﾑﾘﾎﾟ