05/03/05 00:10:44
Cecil
URLﾘﾝｸ(www.cs.washington.edu)
URLﾘﾝｸ(www.kmonos.net)
Cel
URLﾘﾝｸ(www.redwoodsoft.com)
soopy
URLﾘﾝｸ(soopy.sourceforge.jp)
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)
ECMAScript
URLﾘﾝｸ(www.ecma-international.org)
NewtonScript
URLﾘﾝｸ(wsmith.best.vwh.net)
URLﾘﾝｸ(www.cc.gatech.edu)
3:デフォルトの名無しさん
05/03/05 00:16:42
Io 文書Io Documentation
URLﾘﾝｸ(f21.aaa.livedoor.jp)
プログラミング言語 Io のはなし
URLﾘﾝｸ(shinh.skr.jp)
4:デフォルトの名無しさん
05/03/05 00:22:04
SELF: The Power of Simplicity (和訳)
URLﾘﾝｸ(www.ice.nuie.nagoya-u.ac.jp)
＃原文はいずこ。。。？
5:デフォルトの名無しさん
05/03/05 00:36:48
NewtonScript
URLﾘﾝｸ(www.k-inet.com)
URLﾘﾝｸ(www.kallisys.com) (Projet Einstein)
6:デフォルトの名無しさん
05/03/05 01:04:04
SELF and the Origins of NewtonScript
This is an introduction to the paper "Self: the power of simplicity", by Ungar and Smith.
URLﾘﾝｸ(wsmith.best.vwh.net)
7:デフォルトの名無しさん
05/03/05 02:09:18
ruby並に普及すればいいね。まあ無理だろうけど。
8:デフォルトの名無しさん
05/03/05 04:14:47
Luaは違うのか
9:デフォルトの名無しさん
05/03/05 13:15:57
>>7
Rubyも特異メソッドに注目すればプロトタイプベースだよ。
URLﾘﾝｸ(ruby.mirror.easynet.be)
URLﾘﾝｸ(mput.dip.jp)
10:デフォルトの名無しさん
05/03/05 16:37:19
うーん、だからそういうあんま共通点のない言語の集めてどうすんだよ。
プロトタイプならでわの話題があるわけでもなし。
ここでいままでされてきた話って、そういう風にも組めますね、だから何？
で終わりじゃないか。
プロトタイプベースにしたらプロジェクトに成功したとか、金持ちになったとか、
こんなメリットがあった、みたいな話を聞きたいな。
11:デフォルトの名無しさん
05/03/05 16:39:37
うーん、だからそういうあんま共通点のない言語の集めてどうす
んだよ。 プロトタイプならでわの話題があるわけでもなし。
ここでいままでされてきた話って、そういう風にも組めますね、だから何？
で終わりじゃないか。 プロトタイプベースにしたらプロジェクトに成功し
たとか、金持ちになったとか、 こんなメリットがあったよ、みたいな話を聞きたいな。
12:デフォルトの名無しさん
05/03/05 17:02:07
＞あんま共通点のない言語の集めてどうすんだよ。
＞プロトタイプならでわの話題があるわけでもなし。
だったら前スレは1000まで全うせんかっただろう。
まあ、POOのメリットを探るってのは欲しいな。
金持ちになれるかどうかは置いといてｗ
13:デフォルトの名無しさん
05/03/05 17:08:14
プロトタイプベース・オブジェクト指向って
JavaScriptのことだろ。
すでに十分普及している。
14:デフォルトの名無しさん
05/03/05 17:10:21
> クラスでの定義の具体例（インスタンス）としてオブジェクトを
> 生み出すのではなく、既存のオブジェクトの複製（クローン）、
> あるいは、それへの参照を持つことですべてを委譲する
> オブジェクト（チャイルド）を生み出す手法で
あーだめだ。今チャイルドと聞くと舞HiME思い出してしまう。
終わってから忘れるまであと半年ぐらいまってくれ。
15:デフォルトの名無しさん
05/03/05 17:10:46
POOてなんだよ。
馬鹿にしてるのッ！
16:デフォルトの名無しさん
05/03/05 17:11:11
ﾌﾟｰ
17:デフォルトの名無しさん
05/03/05 17:13:16
>>16
プルートのことかーーー！
18:デフォルトの名無しさん
05/03/05 17:13:35
ぷーはメリットよりデメリットの方が多そうだが
19:デフォルトの名無しさん
05/03/05 17:17:55
>>18
タブーを犯すと刈られるしな。
20:デフォルトの名無しさん
05/03/05 17:19:24
まあ、実質JavaScriptスレなわけだが。
21:デフォルトの名無しさん
05/03/05 17:20:49
URLﾘﾝｸ(jp.rubyist.net)
POOのメリットを活用しているRubyは、オライリーも出るほど普及してる。
どうせTraitsがなきゃやってられないんだから、
原理主義に陥らずメリットをうまく活かすのが吉かと。
22:デフォルトの名無しさん
05/03/05 17:23:41
オライリーも、それほどネタに困っているということだな。
23:デフォルトの名無しさん
05/03/05 17:26:48
可読性とかについて語りたい。
個人的にはパスタをおいしく作る方法にしか見えない。
24:デフォルトの名無しさん
05/03/05 17:26:58
>>20
巣に帰れ
25:デフォルトの名無しさん
05/03/05 17:31:13
>>23
POOがなぜ可読性を下げると？
まあ、メソッドの定義がどれかってのを追うのはあれかな。
26:デフォルトの名無しさん
05/03/05 17:34:42
とりあえずPOOがどんなものか
語れ。
27:デフォルトの名無しさん
05/03/05 17:39:11
>>25
23じゃないが、つまり、処理を追わないとオブジェクトが
どんな機能を持つかわからないという事じゃないかな。
これはドキュメントを書くときにも困る。
静的型ならデータ型と、メソッドについて書いていけばいいが、
プーだと処理についても言及しなければならない。
28:デフォルトの名無しさん
05/03/06 09:59:13
処理を追わないとわからないというのは、使い所を誤ってないかな?
Ruby等でもクラス/インスタンス特異を 無闇に 使ってると可読性が落ちるのと一緒。
29:デフォルトの名無しさん
05/03/06 12:32:13
>>28
得意メソッドの正しい使い方を教えてください。
標準ライブラリのstringクラス拡張する奴とかがそれ？
30:デフォルトの名無しさん
05/03/08 00:21:29
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
こいつが猛烈に欲しいのですが……
31:デフォルトの名無しさん
05/03/11 03:26:08
>処理を追わないとわからないというのは、使い所を誤ってないかな?
クラスとプロトタイプなオブジェクトと、両方が使えるんなら「使い所を誤ってないかな?」
という反論が有効だけど、そもそもクラスがない言語じゃどうしようもないよねえ。
なんかこう、クラスなんかなくてもいいぜ! 的なパラダイムシフトを求めてたんだが。
無理な話?
32:デフォルトの名無しさん
05/03/11 21:31:01
>>31
関数型言語いじってみると結構パラダイムシフトするかもよ
つーか（呼び方はともかくとして）プロトタイプベースだからクラスはないってことはないぞ。
33:デフォルトの名無しさん
05/03/11 22:39:50
>>32
インスタンスの初期のメソッドのセットを定義するもの。
とか地味な存在になる感じですか？
34:デフォルトの名無しさん
05/03/12 18:17:52
この場合の、プロトタイプで用いるクラスってのは、
オブジェクトをハッシュデータ構造と考えて、
コンストラクタ ... 自分自身のクローン/コピーを返すメソッド
継承 ... データのマージ
程度で十分じゃないかな。フルセットの"クラス"は実装されてない言語もあるが、
クラスに相当するオブジェクトを作れば、プロトタイプでも従来どおりの記述が出来る。
35:デフォルトの名無しさん
05/03/13 12:23:25
ハッシュって、テーブルでリソース食いまくりな気がするんだけど、
そういうのは無視？
36:デフォルトの名無しさん
05/03/13 17:30:09
>>35
関係ない
37:デフォルトの名無しさん
05/03/14 00:40:00
>>36
何が？
38:デフォルトの名無しさん
05/03/14 01:17:17
ハッシュル！ハッシュル！
39:デフォルトの名無しさん
05/04/19 11:34:08
protoとparentの違いがやっと分った。
protoは意味上の親を表わし、
parentは構造上の親を表わすわけね。
しかしparentはGUIのイベント伝播以外に使いどころが
あるのだろうか？
40:デフォルトの名無しさん
05/04/19 23:13:24
こんな中途半端な概念の物やるよりはhaskellとか関数型言語やった方がいいよ
41:デフォルトの名無しさん
05/04/21 12:42:29
HaskellでGUIはきついぞ？
42:デフォルトの名無しさん
05/04/22 20:23:56
そうか？
そうか・・・
43:ec
05/04/23 23:58:10
>>40
プロトタイプベースが中途半端だということですか？
クラスベースは中途半端ではないのですか？
どこが中途半端なのか教えてください。
44:デフォルトの名無しさん
05/04/24 00:35:56
>>43
関数型言語と言ってるからクラスベース言語とは関係無いでしょう。
何かと言うとクラスベースを持ち出したがるのはこのスレの悪いクセだな。
>>40
プロトタイプベース言語もそれなりにとんがっている言語だと思うよ。
歴史的には Lisp/Scheme とかとクロスオーバーしている部分もあるし。
45:デフォルトの名無しさん
05/05/01 19:36:12
>>44
プロトタイプベースOOのスレなんだから、比較対象としてクラスベースが
持ち出されるのはむしろ必然で、
こんなとこで脈絡なくHaskellを持ってくる方が、関数型言語ヲタクの
悪いクセだと思われ。
46:デフォルトの名無しさん
05/05/01 20:32:46
過剰反応だろ
47:デフォルトの名無しさん
05/05/03 01:34:02
多分、動的な型の扱いはまだ研究途上だから、
それより素性のはっきりしたHaskellでもやっとけ、
と言いたいんじゃないの？
48:デフォルトの名無しさん
05/05/03 03:25:05
関数型でも型付きな言語が出てきたのは後からだべ
49:デフォルトの名無しさん
05/05/05 04:06:21
ぱす。
50:デフォルトの名無しさん
05/05/20 09:13:02
309 名前： デフォルトの名無しさん 投稿日： 2005/05/19(木) 21:44:36
けれどクラスという概念をなくしてしまってもいい
オブジェクトの構造・仕組みという抽象的なもので
コード上は現れないようにしても問題ないだろうよ
311 名前： デフォルトの名無しさん [sage] 投稿日： 2005/05/20(金) 06:01:04
>>309
そういう道を進んでいる言語もある。
プロトタイプベースと呼ばれているようだが。
51:デフォルトの名無しさん
05/05/20 23:21:19
さて、プロトタイプるとするか
ぷ
ろ
と
たいぷ
52:デフォルトの名無しさん
05/07/25 23:10:47
nanika
53:デフォルトの名無しさん
05/09/06 18:11:34
ただいまのぷー儲数：０
ﾌﾟｰﾌﾟﾌﾟﾌﾟ
54:デフォルトの名無しさん
05/09/07 02:09:57
オンザフライでメソッドを追加出来るのは今でも魅力的だと思ってる
55:デフォルトの名無しさん
05/09/10 02:57:54
結局は、オブジェクトの定義が動的か静的かって事じゃないの？
クラス継承もインスタンス化も、プロトタイプからの生成も、is-a関係と考えれば、
クラス定義が動的（タイミングが実行時という意味でなく、組み立て可能という意味）
に出来れば、クラスのありなしって、関係ないんじゃね？
CoR云々て、そんなのを中心としたコーディングなんて有り得ないっしょ？
CoR Orientedなんて方法論が確立され無い限り（されるとは思えんが）。
56:デフォルトの名無しさん
05/09/10 08:25:25
あらゆるオブジェクトがクラスであるようなクラスベースなら、プロトタイプベースと同じだね。
そうじゃなくて、毎回クラスとインスタンスを別に作らなきゃいけないとかだと、ちょっと面倒かな。
# プロトタイプからの生成は、 is-a 関係じゃなくても使うよ。兄弟とか。
57:デフォルトの名無しさん
05/09/10 09:32:21
ぷー儲じゃないけど
いじくる必要のないところは効率よくやってほしいもんだ
つまり効率優先派とは常に衝突するな
58:デフォルトの名無しさん
05/09/13 20:58:58
URLﾘﾝｸ(d.hatena.ne.jp)
プログラマのためのJavaScript (7)-
↑JavaScriptのオブジェクト周りが丁寧に解説されてます。
知らない人はぜひこの機会に読んでみては。
# トレイツベースと呼ぶのはどうでしょ？
59:デフォルトの名無しさん
05/09/13 22:37:32
ここは馬鹿の巣窟だな
60:デフォルトの名無しさん
05/09/13 23:03:51
>>59
あなたがTraitsを知らないことだけはよく分かりました。
61:デフォルトの名無しさん
05/09/14 20:54:25
トレイトとクラスの違いがわかんないな。大した違いはないはずだけど
62:デフォルトの名無しさん
05/09/14 21:18:00
>>61
やろうとしていることは同じです。
共通項の括り出しですね。
で共通部分と特有部分の関係を静的に表現するか動的に表現するかという違いではないでしょうか。
静的な表現がクラス-インスタンスで、動的な表現がトレイツ+オブジェクト。
POOのトレイツは単なる役割なので構造的にはクラスベースよりシンプルですね。
クラスベースの場合、インスタンスとクラスの違いは呼び方だけではなくって中身が違いますからね。
63:デフォルトの名無しさん
05/09/15 03:06:32
特定の名前スロットを特殊な使い方(_PROTO_とか）するところだけがなじめないんだけど、そういう実装以外ないのかな？
64:デフォルトの名無しさん
05/09/16 21:17:49
>>63
JavaScriptのことかな。
プロトタイプのようなしくみがないと自動委譲(=トレイツ)ができないけど、
それでもない方が良いということですか？
それとも何か別の案があるんですかね。
65:デフォルトの名無しさん
05/09/16 21:20:35
POOなんてアフォなのやめて
プロパティ指向にしたらどうだ
66:デフォルトの名無しさん
05/09/16 21:51:14
>>64
そういう意味じゃなくて特定の名前スロットが特定の意味を持たされている部分がなにか嫌らしい感じしません？
ＣＰＵで言うところの特定のレジスタだけが特別扱い的なマシン特性の泥臭さがでてると言うか。
名前に機能をbindするのではなく機構として特別な設定を施した実装（スミマセン語彙貧弱で意味不明かも）みたいなものは無いのかと。
Cで言ったらiはintでループ専用みたいな割り振りされているのがキモチワルイというか。（そんな事ないけど→ｃ）
67:デフォルトの名無しさん
05/09/16 21:52:57
>>64
ぱっと分かるだけでもSelf, Io, NewtonScriptがそうだよ。
＞ 特定の名前スロットを特殊な使い方(_PROTO_とか）
68:デフォルトの名無しさん
05/09/16 22:22:53
_が頭についてんだからシステム予約なのはあたりまえだろヴォケ
69:デフォルトの名無しさん
05/09/16 22:28:51
「頭に _ は予約」が常識かどうかは知らないけど
>>66
C++ の this ポインタとかもそうかと。必要悪。
70:デフォルトの名無しさん
05/09/16 22:31:02
schemeみたいにletとかlambdaさえ意味が変わってほっしー☆のかてめえは
71:66じゃないけど
05/09/16 22:49:03
>>70
特定のスロットやら変数やらを特別視するってのは、結構言語仕様上気持ち悪いもんだよ
使い勝手を優先するとそうなる場合も多いんだけど
72:デフォルトの名無しさん
05/09/16 22:53:14
>>63
最新仕様では無事使用禁止だから大丈夫
73:デフォルトの名無しさん
05/09/16 23:04:28
schemeのアレはコンパイラ作るときに困る
74:デフォルトの名無しさん
05/09/17 00:56:01
>>67
SELFは任意のスロット名が使えるから違う。
75:デフォルトの名無しさん
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型の概念入れようと努力したけどﾑﾘﾎﾟ