プロトタイプベース・オブジェクト指向
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
NGNGプロトタイプベース・オブジェクト指向言語について語りましょうよ．
関連リンク >>2
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNGhttp://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/
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/
Io
http://www.iolanguage.com/
soopy
http://soopy.sourceforge.jp/tutorial/soopyindex.html
0004デフォルトの名無しさん
NGNGhttp://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
0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNGプロトタイプベースが普及しない理由を述べよ
0008デフォルトの名無しさん
NGNG0009デフォルトの名無しさん
NGNGやわらかい言語は動的で自由度が高い言語だ．
カタイ言語は静的で制限を設けることによって安全性と効率を得ている．
どっちも一長一短だ．
プロトタイプベースはクラスベースよりやわらかい．
0010デフォルトの名無しさん
NGNGクラスってあまり綺麗な概念じゃないと思うんだけどどうよ？
全てオブジェクトでいいじゃん．
というとクラスもオブジェクトですって答えが返ってくるかもしれないが，
その構造が初心者を混乱させている．
クラスはオブジェクトで，でもオブジェクトはクラスに属している…
0011デフォルトの名無しさん
NGNG0012デフォルトの名無しさん
NGNGいや，用語なんかよりもっと根本的問題だと思う．
http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/img/metaHiera9.gif
これが，Smalltalkのクラス構造…
こんなんで，everything is an object, it's beautiful! とか言ってんの．もう見てらんない．
0013デフォルトの名無しさん
NGNG0014デフォルトの名無しさん
NGNGあと ECMA Script も。
（こういう商売っ気あるのは面白くないのはわかるけど）。
0015デフォルトの名無しさん
NGNGプロトタイプベースの方が現象を純粋に抽象化してるって感じがする。
クラスの概念はモデル化ではなくって（効率を維持した）アルゴリズム記述の容易さ
のためにあるような気がする。
0016デフォルトの名無しさん
NGNGECMA Script (JavaScript) なんか非常に普及していると思うけど。
0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNGそう．
クラスってイデアみたいなもんだよね．
モデルのモデルについて記述しているわけだ．
まぁイデア論は話としては面白いけど空想なわけで，現実のモデル化にクラスはいらないだろう．
もちろん素直なモデル化を妨げるとしても捨てられない利点があるから使われるんだけど．
俺は言語ヲタなので概念的な美しさを第一に考えちゃう．
C < Pascal
C++ < Java
CommonLisp < Scheme
Smalltalk < Self
と思うわけですよ．この気持わかるでしょ？
0019デフォルトの名無しさん
NGNGJavaScript デス
http://pc2.2ch.net/test/read.cgi/tech/1052273054/
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/
ECMAScriptの実装ってけっこうあるんだね．勉強せねば．
0020デフォルトの名無しさん
NGNGJavaScriptをみたところではとてもそんな機能があったようには見えないのだが・・・。
ECMAScriptになってから変わったと？
0021デフォルトの名無しさん
NGNG>>20
ずっと前からあるよ。
ECMAになってから大きい変化は例外かな？
function MyObject(name)
{
this.name = name;
}
MyObject.prototype.hello = function(){ return "hello"; }
o = new MyObject("hoge");
o.hello();
他にも静的スコープ、クロージャはあるし、関数もオブジェクトで
さまざまなプロパティがあったりと、けっこう面白いよ。
0022デフォルトの名無しさん
NGNGMozillaの中身はそれっぽい使いかたしてるな。
0023デフォルトの名無しさん
NGNG0024soopy
NGNGfun main(){do: println "Hello, World!";};
} main();
上の文は、｛ と ｝に囲まれた部分がオブジェクトを表していて、
そのオブジェクトにmainというシンボルを送っています。
オブジェクトにシンボルが送られると、そのオブジェクト内の
同じ名前の要素が返されます。この場合、mainという名前の
関数（実際にはクロージャ）が返ってきます。
そして、返ってきた関数にさらに（）＝ヌル・オブジェクトを
メッセージとして送ることにより、関数が実行されます。
(http://soopy.sourceforge.jp/tutorial/soopycontent8.html)
かっこいい!
メッセージモデルが素直に説明できる．
一般的なOOPLのメソッド起動も引数指定もメッセージに統一されてる～
0025デフォルトの名無しさん
NGNGでもSelfってスロットのモデルがすっきりしないんだよね。
SmalltalkのClass, Metaclass周りのグジャグジャと同じぐらいグジャグジャ。
0026デフォルトの名無しさん
NGNG＞soopyの構文は非常に単純です。大きくわけると次の５種類だけです。
とあるのに、結局は
＞do:
とかの特殊な意味付けの構文（プロパティ？）が色々あるのって、
なんか騙されてる気がするのだが（ｗ
大別してifとloopの２種類ってことらしいけど、
制御構造はまだまだ考慮の余地が残されてる様な。
まそれはおいといて、
メソッド周りの作りは良くまとまってると思った。
0027デフォルトの名無しさん
NGNG>＞do:
>とかの特殊な意味付けの構文（プロパティ？）が色々あるのって、
>なんか騙されてる気がするのだが（ｗ
書きやすさ、読みやすさに配慮したからでしょう。
あなたなら、どうする？
>制御構造はまだまだ考慮の余地が残されてる様な。
>まそれはおいといて
例外も意外とショボイ。でもパターンマッチがある(w
まあ後は自分で作れということでしょう。
0028デフォルトの名無しさん
NGNGprintln "Hello, World!"
で、"Hello, World!" がメッセージというのにはちょっとびっくり。
do: と同様に、従来のALGOL系文法の手続き型言語に馴染んだ人が
逆にびっくりしないような配慮が多くなされている言語のようですね。
個人的には Io に注目しています。SelfのいいとこどりのNewtonScriptの
さらにいいとこどりのような言語で、非同期メッセージ送信までサポート
しています。難点は、Selfと同様、ググったときに欲しい情報になかなか
行き当たらない名前ってところでしょうか(^_^;)。
0029デフォルトの名無しさん
NGNGUIレイアウト等のデータ構造記述に混ぜてコードを書けるのが面白い
ですよね。
myArray := [
{ label: "小さいつづら" doIt: func() begin game.over(); end },
{ label: "大きなつづら" doIt: func() begin game.add5points(); end }};
とか。
0030Io
NGNG今度じっくり読もっと．
+ プログラム言語 Io のはなし
http://f21.aaacafe.ne.jp/~kizz/prog/io/ref/iovm_ref_j.html
+ プログラミング言語Io リファレンスマニュアル
http://user.ecc.u-tokyo.ac.jp/~s31552/wp/io/
0031デフォルトの名無しさん
NGNGそう。しかもECMAScript4とかになると結局クラスが入ってくるしねぇ。
なんだか残念だ。せっかく綺麗な言語なのに。
>>30
どーでもいいがURLとタイトルが逆だぞ。
0032Io
NGNG>>31 指摘どうも．
大変失礼しました．貼り直しです．
+ プログラミング言語Io リファレンスマニュアル
http://f21.aaacafe.ne.jp/~kizz/prog/io/ref/iovm_ref_j.html
+ プログラム言語 Io のはなし
http://user.ecc.u-tokyo.ac.jp/~s31552/wp/io/
0033デフォルトの名無しさん
NGNG多いに語ってくれ
0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNGDelegation: あるオブジェクトの参照を保持しておき，
自己のメソッド起動をそのオブジェクトのメソッド起動に置き換える
という感じかな？ メソッドで表現すれば．
俺は動的フェチなんでDelegationのが好きだなぁー
0036デフォルトの名無しさん
NGNGそういう意味での独自のオブジェクトか。
既存のオブジェクトの雛形しか使えないことに変わりないわけだね。
0037デフォルトの名無しさん
NGNG>既存のオブジェクトの雛形しか使えないことに変わりないわけだね。
プロトタイプベースなんですけど。。
独自のオブジェクトって、たとえばどういうの？
0038デフォルトの名無しさん
NGNGその方向性なら Forwarding も対象に入るんじゃない？
0039デフォルトの名無しさん
NGNG文法や表現形式はともかく、
意味論的には行った先での self (this) が誰をさしているか、
といった違いになりますか？
>>36
ちょっと意味がわからないので、何か具体例を挙げて話してくれるとうれしい。
"class" っていうキーワードを使ってないからダメ、だとか。
0040デフォルトの名無しさん
NGNG> 意味論的には行った先での self (this) が誰をさしているか、
(プロトタイプ指向で一般的な)動的型付の場合にはそれでいいと思う。
静的型付した時にはその限りでないと思う。
0041デフォルトの名無しさん
NGNGttp://www.kmonos.net/alang/etc/cecil.php
0042デフォルトの名無しさん
NGNG0043デフォルトの名無しさん
NGNG>>3
0045デフォルトの名無しさん
NGNGプロトタイプベースの言語はJScript（苦笑）しか知らないけれど、大好きだよ。
Javaの仕事をした後、JScriptを書いていると、その素晴らしい自由自在さに
コルセットが外れていくような解放感があるよ。
それと同時に、2chのJavaScriptスレッドの「すぐ目先の実用一点張り」な様子は
とても残念だよ。こんなにきれいで面白い言語なのに。
>>31
激しく同意。クラス導入に反対！
0046デフォルトの名無しさん
NGNG0047デフォルトの名無しさん
NGNG0048デフォルトの名無しさん
NGNG学校教育用オブジェクト指向言語「ドリトル」。Java 上で動くプロトタイプベース
言語らしい。
0049デフォルトの名無しさん
NGNGついで。Ruby で実装した Self ライクな環境 SeRuby というのがあるらしい。
0050デフォルトの名無しさん
NGNGLOGOのOO版みたいなもんですね．
論文は会員じゃなきゃ見れないので…
http://www.logob.com/dolittle/
0051デフォルトの名無しさん
NGNGSqueakみたいだね
似たようなことアラン・ケイが小学生にさせてたのを教育テレビで見たことある
0052デフォルトの名無しさん
NGNGvar obj = new Object();
と書いて生成された obj が参照するプロトタイプは、
obj.prototype ではなく、
Object.prototype だ。
だから、オブジェクトのプロトタイプを、生成された個々のオブジェクトごとに
変更することができない。プロトタイプの変更は、同一のコンストラクタから生成された
オブジェクトすべてに影響が及んでしまう。
プロトタイプをオブジェクトごとに、自由に変更できるようにするためには、
オブジェクト一つごとにコンストラクタを一つずつ、用意しなければならない。
まるでクラスベースの型制約に近い不自由さを感じるのだけど。
こんな風に書けたらよかったのに。
var obj;
obj.foo = function(){ alert("ふー！"); };
var obj2;
obj2.prototype = obj;
obj2.foo(); // "ふー！" と表示。
どうしてこうならなかったんだろう？
0053デフォルトの名無しさん
NGNG>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 ] が何を返すべきなのか分からんけど。
005453
NGNGprintln が、オブジェクトなのか、文字列オブジェクトに対するメッセージなのか、
出力先オブジェクトに対するメッセージなのか、言語によって捉え方が色々で
面白いなぁと。
調べてみたら、Smalltalk では「show: 'Hello World!'」で一つのメッセージという
カウントをしてるんですね。
0055デフォルトの名無しさん
NGNGECMAScriptではなくて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(); // "ふー！" と表示。
0056デフォルトの名無しさん
NGNGobj = new Object() の参照するプロトタイプは
obj.prototype ではなく Object.prototype ではなく、 obj.[[prototype]]。
スクリプトからは明示的な読み出しも書き換えもできないので
困る、っちゅーのはその通り。
005752
NGNGおお、詳しい方ですね！__proto__なんて、昔オライリーのサイ本でチラッと
目にして以来忘れていました。
NN7で試したら、動きました。今でもちゃんと動くんだなあ。
IEで動かないのが残念。
あつかましくて恐縮ですが、質問させてください。
1.obj.[[prototype]]の二重カッコはどういう意味なのでしょうか？
2.ECMAScriptは、どうしてプロトタイプを明示して読み書きできないという、
プロトタイプベースの発達の制限をしているのでしょうか？
どういう設計思想なのでしょう？
私はプロトタイプをもっと自由に使いたいのに。
005852
NGNG画面にたくさんのテキストフィールドがあって、
それのイベントハンドラをいっせいに切り替えるようなこと。
画面のモードによって、いっせいにフィールドの挙動を変えるようなこと。
まず↓のようにセットしておけば、
var common;
var proto1;//たくさんのイベントハンドラが定義してある。
var proto2;//同様に定義してあるが、各イベントハンドラの内容は上と異なる。
for (var form in document.getElementsByTagName("INPUT")){
form.prototype = common;
}
↓のように、ごく簡単に複数のオブジェクトの挙動を変えられる。
common.prototype = proto1;//モード1の動作をセット。
common.prototype = proto2;//モード2の動作に変更。
こうなってたら、とても面白かったと思うのですよ。残念だなあ。
005955
NGNG> 1.obj.[[prototype]]の二重カッコはどういう意味なのでしょうか？
「内部プロパティ」のつもり。意味論的にはオブジェクトのプロパティの
一つなんだけど、言語内では触ることのできないシロモノ。
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/8_Types.html#section-8.6.2
> 2.ECMAScriptは、どうしてプロトタイプを明示して読み書きできないという、
> プロトタイプベースの発達の制限をしているのでしょうか？
実装の最適化のためだと思うよ。「あとから定義が変更できるクラス」
程度の柔軟性が残ってさえいれば、あとはできるだけ高速化しやすい
仕様を選んだんじゃないかと。知らんけど。
006052
NGNGありがとうございます。実装の最適化ですか…。
私は、クラスベースの言語の挙動に似せるためだと思っていました。
具体的にはJavaですね。
一般のプログラマは、非常に保守的ですから。
Java自体、最初はOAKという、FORTHに似た構文の言語だった時には全く人気が出ず、
Cに似た構文を採用してJavaとなってからやっと使われるようになったといいます。
（しかしJavaは5年ぐらいは、「ポインタ演算のできないC」として扱われた）
LiveScript -> JavaScriptも、Javaとの共通性を（ニセのイメージだとしても）打ち出さ
なければ、普及しなかったのじゃないかなと思うのです。
プロトタイプベースの言語は、そのシンプルな美しさに関わらず、いまや絶滅寸前
ですから。
あまりにも自由自在にすると、クラスベースにある堅牢さから遠ざかり、プログラマから
好まれないのではないか、と設計者が考えたのではないかと私は思っていました。
いずれにせよ、私は現状を残念に思います。今のECMAScriptは、貧者のJavaに過ぎない。
0061デフォルトの名無しさん
NGNG「プロトタイプ指向かくあるべき」という先入観を捨ててから、もう数ヶ月ECMAScriptを使い込んでみて欲しい。
・ECMAScript は JavaScript(Netscape) と JScript(IE) の仕様摺り合わせとして
策定されたもの。そして JScript には __proto__ が実装されていなかった。それだけだ。
ECMAScript1.0が出た頃には、普及も何も、既にWWWのクライアントサイド言語としてシェアをほぼ全制覇していたし。
> プロトタイプベースの言語は、そのシンプルな美しさに関わらず、いまや絶滅寸前ですから。
・絶滅という言葉が使えるほど栄光の時代があったパラダイムではないと思うんだけど。
逆に今ならJavaScript があるし、ActionScript (Flash) がある。プロトタイプチェーンくらいはmetatableで
簡単に実装できるだけの柔軟性をもったLua言語も最近流行し始めた。
もちろん各言語のほとんどのユーザはプロトタイプ指向を用いては
いないだろうけど、それでもSelfしかなかった頃と比べたら、今や
プロトタイプな人の数は雲泥の差だ。
006252
NGNGうーん、少々舌足らずだったかも知れません。
ECMAScriptがJavaScriptとJScriptのすり合わせで成立していることは承知している
つもりなのです。
ではなぜ、JScript、JavaScriptがこのような言語になったのでしょうか？
JScriptではプロトタイプはコンストラクタからしかアクセスできず、
JavaScriptでも__proto__は元々隠し機能であり、いつ廃止されるかわからない
状態だった。
それはやはり言語設計者が、プロトタイプを自由に扱わせることに、この言語の普及において
メリットよりデメリットを感じたからだと思うのです。馴染みにくいから。
また、そういうニーズは少ない。ネットを見回すと、JavaScriptでオブジェクト指向を
実現しようとする試みはたくさん見つかりますが、そのほとんどが「いかにしてJavaと
同じ事をするか」に腐心しています。それに対して、JScriptがプロトタイプを公開して
いないことに対する不満を主張するサイトは、私はまだ一度も見たことがありません。
プロトタイプベースの言語が世に広まってきたとは言え、そのほとんどのユーザにその意識が
無いままでは、いつまでも「Javaより貧弱な言語」と見なされるだけで終わってしまうのでは
ないかと思うのです。
006352
NGNGベースなんて意識することもありませんでした。
今書いたようなことは、Googleで偶然に
http://squab.no-ip.com:8080/wiki/search?search=%83v%83%8D%83g%83%5E%83C%83v&casesensitive=false&and=true
このあたりにたどり着いて、中途半端に感化されてしまっただけのことなんです。
すみません。
ただ、今まで オブジェクト指向 ＝ クラスベース としか思っていなかった私には、
まさに目からウロコだったのです。
プロトタイプによる委譲という単純な仕掛けだけで、クラスベースと同等以上の
記述性をもった言語が成立するというのが新鮮だったのですね。
年季の入った人からは稚拙な主張だと思います。
だから、皆さんがプロトタイプベースの言語とどのように付き合っているのか、
お聞かせ願えたらと思います。
例えば、ECMAScriptはこう書けば、このように自由なことができる、とか。
この言語は、このように便利だ、とか。
0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNG0066デフォルトの名無しさん
NGNG0067デフォルトの名無しさん
NGNG0068デフォルトの名無しさん
NGNG0069デフォルトの名無しさん
NGNG0070デフォルトの名無しさん
NGNGJavaScriptは、使われ方からユーザがほとんど厨ユーザだからね。
おまいみたいなヤシばっかだったらいいのに。
0071デフォルトの名無しさん
NGNGあとからあとから厨が乱入してくるけど。
0072デフォルトの名無しさん
NGNG実用本位で使うから房っていうのは（もしその意図があるなら）頂けないな。
まあ高邁な学者さんのようなご意見だとは思うけどね。
0073デフォルトの名無しさん
NGNGSelf は JIT で結構速いらしいよ。
プロトタイプ言語のオーバーヘッドは結構大きそうな感じはするけどね。
0074デフォルトの名無しさん
NGNGそうばかりは言えないよ。あなただって、Java で COBOL みたいなコーディングを
している人がいたら「もうちょっと言語を理解して使ったほうがいいんじゃないの？」
と思うでしょ？
0075デフォルトの名無しさん
NGNG別にコンストラクタをたくさん用意しなくても、プロトタイプを自由に変えることは
できる。生成されたオブジェクトが参照するのは、 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!」と表示
0076デフォルトの名無しさん
NGNG厨なコードを「実用本位」と呼ぶことは、本当に実用になるコードを書く職人さんに失礼。
007775
NGNGこれが FactoryMethod パターンと State パターンを組み合わせたものに
近い、と感じられないかな。
a と b が State ね。
オブジェクト指向言語には、既存のオブジェクトの機能を利用して新しいオブジェクトを
作る方法が、大きく分けると2つある。「継承」と「委譲」。
クラスベースの言語は、言語レベルで「継承」をサポートし、
プロトタイプベースの言語は、言語レベルで「委譲」をサポートしたものだと
言えると思う。
上と似た動作のコードは Java でも書けるけど、かなり煩雑になる。
007875
NGNGJavaScriptは、せっかく言語レベルで委譲をサポートしているのだから、委譲を中心に
活用するのが良いと思う。
Java の真似をして、継承という枠組みで使うのは、無理があるし、もったいない。
0079デフォルトの名無しさん
NGNG気がする。
0080デフォルトの名無しさん
NGNGなんで？クラスなんて全然関係ないじゃん。
0082デフォルトの名無しさん
NGNG委譲の発祥がクラスベースって言うんだったら
そもそも最初のOOPLがクラスベースだったんだから(ry
0083デフォルトの名無しさん
NGNGそもそも漏れみたいな厨は、それが委譲のオリジンだと思ってた。
0084デフォルトの名無しさん
NGNG「あるオブジェクトが、自分の実装していない機能があったとき、別のオブジェクトから
それを借りてくる」
という点では変わらない。
で、継承は、オブジェクトを作る金型（クラス）の間で、機能の貸し借りをするの
だけど、
委譲は、実際に生成されたインスタンスの間で、機能の貸し借りが行われる。
型なし言語（だった）JavaScriptが委譲を採用しているのは、まあ当然かも。
0085デフォルトの名無しさん
NGNG> 型なし言語（だった）JavaScriptが委譲を採用しているのは、まあ当然かも。
型とクラスが混ざってないかい？
0086デフォルトの名無しさん
NGNGプロトタイプ・チェインはむしろ単一継承にたとえられることが多いはず。
多重継承は、一回の継承で複数個の親クラスを持つことでしょ？
歴史的経緯については私も知らない。すまん。
0087デフォルトの名無しさん
NGNGあー、俺は83じゃないが、たぶん83が言いたいのは、
単一継承のOOPLで多重継承的なことをやるために委譲が使われた、
みたいな感じのことだと思われ。
0088デフォルトの名無しさん
NGNGん？あなたが言っている型というのは、プリミティブ変数の型のことかい？
私はクラスを、オブジェクトの型として構わないと思うのだけど。
さしさわりがあったら、教えてほしい。
0089デフォルトの名無しさん
NGNGなるほど、了解。これは私の読み違いだったか。
0090デフォルトの名無しさん
NGNG例えばJavaにはオブジェクトの型としてインターフェイス型なんてものあるねえ。
ついでに言えば、Smalltalkはいわゆる型なし言語(正確には動的型付言語)
と言われているが、コテコテのクラスベースOOPLだよ。
0091デフォルトの名無しさん
NGNGええと、私は「型」というものを、「変数の、ある機能を保証するもの」と
見なしている。例えば、数値型だったら、四則演算が保証される、というように。
同様に、例えばあるインスタンスがコレクション・インターフェースに属していたら、
それはイテレータによる処理が保証されるわけだから、これをオブジェクトの
型とみなして良いと考えていた。
それに対して、プロトタイプベース言語は、実行するまでその操作が可能か、事前には
分からない。型による保証がない。
こういうイメージで、クラス（ないしはインターフェース）を「型」の一種と考えている
んだけど、まずいだろうか？
0092デフォルトの名無しさん
NGNGSmalltalk については、知らないのでなんとも言えない。
だけど、型なし言語だったら、プロトタイプベースのほうが自然なんではないか
という気がする。オブジェクトの機能の貸し借りに、クラスというものを介在
させずにすむから。
ということで、機会があったら、勉強してみます。
0093デフォルトの名無しさん
NGNGclass は C++ みたいな言語での、継承の階層図での位置だよね。
対して interface は、 method とかの集合だと思う。
静的で class-based な言語なら一意に対応するだろうけど、
動的な言語だと interface だけ変えるとか、 class だけ変えるとかができそう。
0094デフォルトの名無しさん
NGNG> だけど、型なし言語だったら、プロトタイプベースのほうが自然なんではないか
> という気がする。オブジェクトの機能の貸し借りに、クラスというものを介在
> させずにすむから。
どうだろうね。
プロトタイプベースではオブジェクトの型紙としての機能を全オブジェクトに持たせるのに対して、
Smalltalkではオブジェクトの分担をはっきりさせ、
Classクラスのオブジェクトにその機能を集中させて専業させることで
その他のオブジェクトを簡素化している、
とも言えるわけで、
全てのオブジェクトにオブジェクト生成機能を持たせるSelfと
オブジェクト生成機能を特定のオブジェクトに専門化させたSmalltalk。
つまり
比較的単質なオブジェクトの集合としてオブジェクト世界を構築するSelfと
色々な種類のオブジェクトの集合としてオブジェクト世界を構築するSmalltalk。
その一方で、
固定的な種別を排除した雑多なオブジェクト世界を構築するSelfと
クラスという明確な種別による整然としたオブジェクト世界を構築するSmalltalk。
結局はコインの表裏ってとこだよ。
どっちが自然というよりは、モデリングの視点が違っているだけの話だと思う。
あとは趣味の問題。
0095デフォルトの名無しさん
NGNG0096デフォルトの名無しさん
NGNGまあそんなもの。
属性名とスロットインデックスの対応とかメソッド辞書等の、
オブジェクトの構造や機能に関する情報と、
それを使ってオブジェクトを生成する操作。
0097デフォルトの名無しさん
NGNGなるほどねえ。
プロトタイプベースについて論じるためには、実はクラスベースについても
広くきちんとした知識をもっていなければならないのだなあ。
勉強になりました。
0098デフォルトの名無しさん
NGNG>>93のように、Smalltalk って、インスタンスの属するクラスをを動的に変更
できるの？まさか、キャストのことじゃないよね？
インスタンスが生成されたあとでも、その属するクラスを動的に変更できると
したら、プロトタイプベースと同等の自由度だよね？にわかに信じがたい。
もし本当なら、Javaでは信じられない世界だ。
0099デフォルトの名無しさん
NGNGここら辺が参考になるかと。
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
>その属するクラスを動的に変更できると
>したら、プロトタイプベースと同等の自由度だよね？
サブクラシングせずに、オブジェクト毎にメソッドを追加／上書き出来ないと
同等じゃないと思う（個人的には）。
私はプログラマでも言語実装者でもないので、全部伝聞でｽﾏｿ。
01001
NGNG01011
NGNG>したら、プロトタイプベースと同等の自由度だよね？
そこまでしてクラスに拘る理由があるのか疑問．
そうやってどんどんクラスベースに柔軟性を持たせると，
結局プロトタイプベースと同じものになるだろう．
そうなったらクラスという概念が無い方がシンプルでわかりやすい．
自由度と危険性を手に入れたいならクラスという概念はいらないはず．
0102デフォルトの名無しさん
NGNG基盤をクラスに置く事は何の不思議もないと思うけど。
0103デフォルトの名無しさん
NGNGそうかな？
あるオブジェクトのインスタンスがあって、モードによってその動作を
ガラッと変えたい、なんて場合には、ぜひとも既存のインスタンスの
属すクラスを、別のものに変えたいと思うけどなあ。
GUI の設計とかしていると、よくそういうことない？
というか、Java でよく使う Stateパターンって、動的にクラスの
変更のできない言語で、委譲先を変えることによって機能をそっくり
取り替えてしまおう、というものでしょ？
（まあ、メソッドの内容は変えられても、シグナチャは変えられないんだけど）
ということで、今はそんなにクラスの変換は行われていなくても、もし言語が
それをサポートしているなら、需要はいくらでもあると思う。
0104デフォルトの名無しさん
NGNG自己訂正。
State パターンで変えられないのはシグナチャ、という言い方は不適切だな。
メソッド自体を新設したり、廃止したりということはできない、とすべきだった。
0105デフォルトの名無しさん
NGNG> ということで、ややスレ違いで恐縮なんだけど、
> >>93のように、Smalltalk って、インスタンスの属するクラスをを動的に変更
> できるの？まさか、キャストのことじゃないよね？
キャストじゃないよ。そもそもSmalltalkは動的型付だからキャストは存在しない。
> インスタンスが生成されたあとでも、その属するクラスを動的に変更できると
> したら、プロトタイプベースと同等の自由度だよね？にわかに信じがたい。
> もし本当なら、Javaでは信じられない世界だ。
とりあえず簡単なやり方としては、
1. 自分相当のオブジェクトを違うクラス(仮にAnotherMyClassと呼ぶ)で生成する。
newSelf ← AnotherMyClass from: self.
2. 自分をnewSelfにする。
self become: newSelf.
これで、今までの自分とはサヨナラ、これからの私はAnotherMyClassのオブジェクトです、
となる。
ちなみに>>99さん、become:はまだ生きてますよ。
というか、Smalltalkはこれがないと根本的に動かない。
0106デフォルトの名無しさん
NGNG素晴らしい！Smalltalk ってそんなに自由なのか！
クラスベースにも、こういう可能性があったのですね！
こんなJava厨の質問に答えてもらって申し訳ない。
ありがとう、>>105の中の人！
0107Java厨
NGNG0108デフォルトの名無しさん
NGNG#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)
このようにインスタンスとそのクラスとの委譲関係は自由にはできませんが、
クラスをしてそのスーパークラスとの委譲関係は比較的自由に乗り換えられる
ことは話の流れ的には強調してもよいのかな…、とも。
0109105
NGNG> 完璧に化ければそれはもはや本人と見なしてよいか…という問題をはらんでいます。
ようするにアイデンティティをどう捉えるのかという問題ですね。
あなたはSmalltalkerのようなのでSmalltalkで答えると、
anOrderedCollection ← OrderedCollection new: 0.
anOrderedCollection addAll: #(1 2 3 4 5)
ここで、2行目の実行前と実行後で、anOrderedCollectionが同じオブジェクトで
あると看倣す人であれば、become:によってクラスを変更できると答えるべきだと
思いますが、いかがでしょう？
> 状況を限定すれば、 Hoge become: Hage を使って注目するインスタンスの
> 「クラスは変わった」と判断してもよいように思います。
クラスオブジェクトにbecome:を使うと色々と後片付けが面倒なんで・・・
不可能とは言いませんが、それこそ特定のクラスに対して、よほど注意しながら
でないと使うべきではない手ではないかと。
＃じゃ非クラスインスタンスに対してはbecome:を気軽に乱発していいかというと(ry
0110105
NGNGスレ汚しスマソ。
0111デフォルトの名無しさん
NGNGいや、ちっとも迷惑じゃないです。
ということで、>>107 について簡単でよいから教えていただけませんか？
私も知りたい。
0112デフォルトの名無しさん
NGNG実際どうなんでしょ？柔軟性という点ではプロトタイプベースとタメを
はれるんでしょうか？
0113デフォルトの名無しさん
NGNGクラスの付け替えは、閉じた環境の中で実装しながら設計するという Smalltalk や
Lisp 特有のニーズだと思っていたけど、そこまで積極的に使いたいなら >>101 の
言うように最初からプロトタイプベースの言語を使用した方が良いのでは?
クラスは型システムみたいにある種の保証を持たせたり、最適化のポイントとして
使われる場合もあるから、ほいほい変えられるものじゃないと思うけど。
実際初期の Squeak では、オーバーヘッドを考えて become: の使用をなるべく
減らす様な実装にしていたらしいし（処理系依存だけど）。
0114105
NGNG簡単に言うと、今まで自分を指していた参照が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のインスタンスが生成されます。
0115105
NGNGSmalltalkではOrderedCollectionという可変長配列みたいなクラスがあります。
これはどうやってサイズを可変にしているのかというと、
自分よりちょっと大きなサイズのOrderedCollectionのインスタンスを作って、
中身に自分の中身をザクっとコピーしておいて、
そいつにbecome:するのです。
つまり、厳密に言えばそのオブジェクト自体が可変長なのではなくて、
別のサイズのコピーにbecome:することで「実質的に」可変長になっています。
(多少のサイズの変動はbecome:することなしにfirstIndex, lastIndexで調整しますが)
ここで、新しいOrderedCollectionのインスタンスを作るとき、
新しい大きさに適した別のクラスのインスタンスに変更していくことも可能です。
(現在の実装では、ずっと同じクラスのインスタンスのままです。)
>>109で、OrderedCollectionのサイズ変更前と後とで同じオブジェクトと看倣すの
であればクラスも動的に変更できると看倣すべき、と言ったのは、この意味です。
じゃ、これでこの流れのSmalltalkネタは最後にしますです。
また面白そうなネタがあったら口を挟ませてもらいます。
0116デフォルトの名無しさん
NGNG「クラスベースのオブジェクト指向言語は
リファレンスマニュアルが書きやすいからいいんだよ」
とても納得した。
0117デフォルトの名無しさん
NGNG予備知識がなくて難しいですが、ある程度分かった気がします。
become: というのは、他のインスタンスを自分のアドレスにコピーすることなのですね？
それなら、オーバーヘッドが大きいのも分かります。
from: の実装次第で、どのようなクラスに変えることができるのも分かりました。
>>108-109 については、正直「なんとなく分かった？」程度ですが、自分としては
一応満足です。さすがにこれ以上はスレ違いでしょうし。
丁寧にご説明いただき、大変ありがとうございました。
0118デフォルトの名無しさん
NGNGその一つは型チェックだと思うんだけど、Smalltalkのようなインタプリタだと
その利点もなくなるし、結局なにがいいのかな？
0119デフォルトの名無しさん
NGNGSmalltalk言語処理系は基本的にコンパイラベースです。Smalltalk環境内であまりに
自在にコードを評価できるので勘違いされがちですが…。いちおう、念のため。
クラスベースのアドバンテージですが、結局は型チェックの例と同様に、ある種の
制約を課すことによる安心感、安定さ、安全性に尽きると思います。
クラスベースとプロトタイプベースをコインの表裏、テーゼとアンチテーゼのように
例える向きもありますが、それよりむしろ、クラスベースはプロトタイプベースが実現できる
システム形態のひとつだと考えるほうがいろいろなことをうまく説明できます。
Smalltalk 処理系を Self で比較的すなおに実装できるのに対して、逆はそうでは
ないことなどは、その良い例でしょう。
0120デフォルトの名無しさん
NGNGふーん、クラス無いの。静的型チェックも出来ないんだ。
オーバーヘッドも大きそうだし、そんなにころころ挙動が
変わったらドキュメント作る時どうするの。そんなふわふわ
した言語でコーディングなんて出来ないよ。学者さんの研究
じゃないからね。こっちは仕事で納めるコードを書いてるんだ。
って言われない事。
0121デフォルトの名無しさん
NGNG> Smalltalk 処理系を Self で比較的すなおに実装できるのに対して、逆はそうでは
> ないことなどは、その良い例でしょう。
んなわきゃない(苦笑
0122デフォルトの名無しさん
NGNGころころ挙動が変わらないようにプログラム組めば？
プロトタイプベースでももちろんできるけど。
挙動がころころ変わるような柔軟な処理も組めて、
挙動が変わらないプログラムも組める。
ところが、クラスがあると柔軟には組めない。
0123デフォルトの名無しさん
NGNGクラスはあるが。
0124デフォルトの名無しさん
NGNG> ところが、クラスがあると柔軟には組めない。
どうして？例えばこのスレでも何度か話題に出てるSmalltalkなんかは
実行中にクラス定義を変化させたり、メソッドを定義したりできるじゃん。
それに1クラス1オブジェクトにすればプロトタイプベースと変わらなくなるし、
1クラス複数オブジェクトも可能な分だけ柔軟性があるとも言えるじゃないの？
つーかさ、クラスベースだからとかプロトタイプベースだからとかナンセンスでしょ。
柔軟性をキーワードにしたって、双方にそれぞれの利点と欠点があるわけでさ。
0125デフォルトの名無しさん
NGNGこのスレの議論は実にありがたい。
皆さん、どうかもっとガンガンやって下さい。
つうか、議論が長くなってくると、wiki より 2ch の方が見やすいなあ。
0126デフォルトの名無しさん
NGNG>制約を課すことによる安心感、安定さ、安全性に尽きると思います。
>そんなにころころ挙動が
>変わったらドキュメント作る時どうするの。そんなふわふわ
>した言語でコーディングなんて出来ないよ
クラスベースの利点やプロトタイプベースの欠点は、抽象的にはこうした意見に
集約されるようですが、もっと具体的に知りたいです。
例えばSmalltalkは柔軟なのだからこれは当てはまらないのではないですか？
当てはまるとしたら具体的にどういった例が挙げられますか？
0127デフォルトの名無しさん
NGNGいや、そういう事じゃないんだけど・・・。
クラスがあるのは良いけど、クラスに色々盛り込み過ぎなんだよなぁ。
0128デフォルトの名無しさん
NGNGCLOS / MOP についてはここを読むといい。
ttp://www.geocities.co.jp/SiliconValley-Oakland/1680/clisp/index.html
ttp://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi
0129デフォルトの名無しさん
NGNGそんな理由で、Smalltalk を鼻にもかけない人や、プライベートプログラミングとしては
楽しいけど、仕事で使うのはちょっと…とためらう人が多いのではないでしょうか。
＞Smalltalk は柔軟だから当てはまらない
クラスベースの目指すところからしたら、Smalltalk や CLOS はさながら
鬼っ子か異端児といったところでしょうから、この二者が反例を呈すから、それは
クラスベースの特徴 or 制約ではないと言い出すと、ここでの対比や理解を深めることを
難しくしてしまうように思いますがいかがでしょう。
0130デフォルトの名無しさん
NGNGttp://research.sun.com/research/self/release_4.0/smalltalk.html
0131デフォルトの名無しさん
NGNGで、Smalltalk上にSelf(-like)環境を構築するのは困難とする根拠は？
0132デフォルトの名無しさん
NGNGSmalltalkじゃないけどRubyでSelfライクな環境を構築した例なら、ほれ。
すげー短いコードだし。
ttp://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/seruby/
01331
NGNGhttp://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/index.html
このスレ的にけっこう関係ありかと思われ．
単一分類と静的分類に縛られては素直なモデル化ができない．
上位工程では多重分類と動的分類をモデル化に用いて，
途中でそれを単一分類と静的分類に書き直し，
一般的なオブジェクト指向言語で実装する．
でもプロトタイプベースについては一言も触れられてないのが残念．
0134デフォルトの名無しさん
NGNGどちらが良いなんて無い。どちらが（自分の問題領域に）向いているかで
考えれば良い。
だいたい、オブジェクトシステムなんてこの 2 者以外にも色々モデルが
ある訳だし。
0135デフォルトの名無しさん
NGNGなんか、大学受験の現代文の文章を読んでるかのごとく、
わかりにくい。
もっとこう、解説本のように具体例を挙げて説明してくれんかな。
0136デフォルトの名無しさん
NGNGプロトタイプベースはオブジェクトだけだが、クラスベースはいろんなクラスがある。
つまり、視点が違うんだ！
0137デフォルトの名無しさん
NGNGClassクラスのオブジェクトって？
0138Java厨
NGNG0139デフォルトの名無しさん
NGNGオブジェクト管理システムとして、クラスを使いたいかどうかって事でしょ。
クラスベースの場合、変数やメソッドの追加はクラスを通して行う。逆に言うと
オブジェクトの定義はクラスを見に行けば良い。オブジェクトはクラスの実体化
に過ぎないから、オブジェクト同士の比較やオブジェクトの型の保証等々はクラス
を使う事で簡単に実現出来る。
プロトタイプベースだと、変数やメソッドはオブジェクトローカルで自由に変え
る事が出来る。逆に、オブジェクトのメタな情報はそれぞれのオブジェクトが
バラバラに持っている（もちろんクラス相当のオブジェクトを作ってあげて、
そこに登録すれば良い訳だけど）。同じオブジェクトでもタイミングが違うと
全く異なる挙動をする可能性がある。
色々突っ込まれそう・・・。
0140デフォルトの名無しさん
NGNGｺﾞﾙｧ！勝手に異端扱いするんじゃねぇ！ どっちも OO システムとして
はかなり初期なんだから、むしろ後発の連中が静的ﾏﾝｾｰになっちまった
だけだろーが！
0141デフォルトの名無しさん
NGNG私もそういう考え。自信ないけど。
>>140
後発の言語のほうが、クラスベースの良さをよく理解していたのかもしれないよ。
0142デフォルトの名無しさん
NGNG> 後発の言語のほうが、クラスベースの良さをよく理解していたのかもしれないよ。
そうかな？ 型とクラスを安易に対応させる悪弊を撒き散らしたと思ってるけど。
ひどい時にはクラス＝型なんて話が出たりもする。
例えばJavaのインターフェース型なんて、プロトタイプベースでも十分可能でしょ？
つまり、型チェックのためにクラスを導入する必然性はないわけで。
0144デフォルトの名無しさん
NGNGで、 C/C++ が主流。
でも、変更に弱いとつらいってことが、少しずつ知られてきたよね。
computer の性能も、どんどん高くなってきた。
prototype-based とかも、これから見直されてくと思う。
0145デフォルトの名無しさん
NGNGクラスとオブジェクトはもともと Simula-67(のちにSimula)で、それぞれ「ユーザー定義
可能な型」とその「データ(インスタンス)」という位置づけてそう名付けられたものです。
C++はその流れを忠実に受け継いでいるので「クラス＝型」という考え方はなにも間違って
いないと思いますよ。
ただしこれはあくまで抽象データ型の話で、オブジェクト指向からはちょっと離れます。
C++はSmalltalkなどと違って抽象データ型言語としても使えるので、こういう話になります。
抽象データ型とオブジェクト指向でクラス定義や扱いがどう変わるかについては、
クックの論文によく整理されているので興味があればぜひ。
ttp://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf
0146デフォルトの名無しさん
NGNG> ただしこれはあくまで抽象データ型の話で、オブジェクト指向からはちょっと離れます。
その通り。
Simula-67ではデータ型とクラスが一緒くたになっていたが、
Smalltalkではそこからクラスとしての要素を抽出してpure OOにした。
ところがSimula以降の静的型付言語では、あいかわらずデータ型とクラスを
掛持ちさせている。
本来OOにおいてプログラマが気にするべきなのはJavaのインターフェース型のような
そのオブジェクトに可能な操作や観察としての型なわけだが、
処理系のほうはオブジェクトの内部構造のほうを要求していて
静的型付OO言語の設計では、処理系の都合のほうが常に優先されてきた。
効率を度外視すれば、クラスが存在しないプロトタイプベース言語でも
インターフェース型は導入可能で、それにより柔軟性をある程度手放して
実行前に型安全をチェックすることも可能でしょ。理論上は。
まあ、俺はクラスベースでもSmalltalkやPythonのような動的型付言語のほうが
好きな口なんで、静的型に縛られたプロトタイプベース言語なんて使わないと思うが、
インターフェース型ならばまだ妥協して使うかもしれない。
0147デフォルトの名無しさん
NGNG実行時にレシーバのオブジェクトが何であるか決まるオブジェクトシステムで、
実行前に型チェックなんて出来ないでしょう。
0148デフォルトの名無しさん
NGNG> でも、変更に弱いとつらいってことが、少しずつ知られてきたよね。
そうなんだよ。JScriptだと、いきなりコードを書き始めて、少しずつ洗練させていくことが
できるんだけど、Javaだとあらかじめすごく考えてから書き始めないと、すぐ破綻
しちゃうんだよ。
これは自分の頭が悪いせいだと思ってたんだけど、下の文章を見て、ああ、そういう
ことなのかと思ったよ。
簡潔さは力なり
http://www.shiro.dreamhost.com/scheme/trans/power-j.html
芸術では、刺繍やモザイクといったメディアは何を作るかをあらかじめ知っていれば
うまくいくが、そうでなければめちゃくちゃになる。作りながらイメージを発見したい
のなら---例えば人物画のような複雑なイメージを扱いたい時はほとんどそうなのだが---
もっと柔軟性のあるメディア、鉛筆とかインク・ウオッシュ、あるいは油彩が必要だ
ろう。実際、タペストリーやモザイクは最初に画を描いてからそれをコピーすることで
作られている。
0149デフォルトの名無しさん
NGNGのを問題とする人が増えてきて、その解決策としてリファクタリングが取り上げられる
ようになったんだと思うよ。
ファウラーの『リファクタリング』は基本的に、ずっとこんな感じ↓の内容で。
仕事に取り掛かった時点では、私はどういうクラス設計をしたらいいか、いつも
わからないんです。だから仕事に取り掛かるのがいつも怖かったんです。
だけどリファクタリングを知って、「とりあえず動くコードを書くことを目標に
しよう。設計はどうせまずいだろうけど、あとでリファクタリングできるから」
と考えるようになって、すごく安心しました。
この内容、私も本当に同感だったんだけど、>>148 のリンク先を見て、また別の感想を
持つようになったよ。
リファクタリングって、なんつうか、もともと変更に向かないモザイクのような言語で、
なんとか変更を行えるようにしたもの、という気がしてきたんだよ。
まあ、それなりに機能していると思うんだけど、モザイクを「15パズル」のように
いじっているような、もどかしさを感じてねえ。
http://www.game3rd.com/game/puzzle/15puzzle/
0150デフォルトの名無しさん
NGNGまずは何かJavaの入門書を読んでinterface typeが何かを理解したら？
0151デフォルトの名無しさん
NGNG動的言語に適用した場合の具体的な実装とメリットがイメージ出来ないんだけど。
まぁ言い散らかすのは勝手だが。
0152デフォルトの名無しさん
NGNGRefactoringは元々Smalltalkerの流儀から来ている。
Smalltalkはオブジェクトを生かしたまま(つまりプログラムの実行中に)
クラス定義を変更したりメソッドを書き変えたりできるから、
まずは何かとりあえず動くオブジェクトを作ってみて、
動かしながら変数をいじったりメソッドを変更していく流儀が前提にあって、
その中から使用頻度が高く機械的にできる変更のパターンをまとめたのが
Refactoring。
別の言い方をすれば、Refactoringは変更し難い言語で変更を容易にするものではなく
元々どうにでも変更しやすい言語で、変更の仕方を分類整理して名前をつけて、
初心者への教育とか、プログラマ間のコミュニケーションを改善するものだと思う。
だから、変更のし難さというのはクラスベースだからというわけではなく、
むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。
つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と
同一視したことによる縛り。
0153デフォルトの名無しさん
NGNG> だから、変更のし難さというのはクラスベースだからというわけではなく、
> むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。
> つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と
> 同一視したことによる縛り。
うおー、目からウロコだー！ありがとうございます！
>>150-151
議論が噛み合っていない気がするなあ。もうちょっと冷静にやろうよ。
01541
NGNG>その中から使用頻度が高く機械的にできる変更のパターンをまとめたのが
>Refactoring。
はぁ？
リファクタリングはパターンじゃないんですけど…
使用頻度とか機械的だとかコミュニケーションとか関係ないんですが．
リファクタリングとは，ソフトウェアの外部的振る舞いを保ったままで，
内部の構造を改善していく作業を指します．
(リファクタリング プログラミングの体質改善テクニック)
0155デフォルトの名無しさん
NGNGうーん、リファクタリングには定石はあるわけで、それを「パターン」と呼んでも
リファクタリングの趣旨からは離れはしないと思いますよ。
実際、「この長いメソッドは別クラスとして独立させてね」という感じで
パターンを意識したコミュニケーションも行われているし。
まあ、スレ違い気味ではあるが。
0156デフォルトの名無しさん
NGNG「アナリシスパターン」 や 「Smalltalk ベストプラクティス・パターン」 があるように。
名前を付けて体系化することで、暗黙知を形式知とすることと、
コミュニケーションするときの共通語彙として使えるようにすることが
パターンの目的というか役割。
01571
NGNG言いたいことはわかります．
ただ用語の定義が正確ではないと思ったのでレスしました．
「使用頻度が高く機械的にできる変更のパターン」を
リファクタリングと呼ぶのは間違いです．
リファクタリング・パターンとでも言うべきでしょう．
リファクタリングという作業自体には使用頻度が低いものもあるし，
機械的に行うことが難しいものもあるのです．
0158デフォルトの名無しさん
NGNGライブラリ利用時の保証ならクラスブラウザで良いし、実行時の保証ならリフレクションを
使う事になるんじゃないのって事なんだけど。
0159デフォルトの名無しさん
NGNGttp://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/S4-5-5_1.html
ttp://www.sra.co.jp/smalltalk/SML/archives/1999-March/thread.html#3323
Smalltalk でインターフェイスを実装する話。操作の集合としてインターフェイスを
付けるのは良いけど、静的な型システムの代用とはならない。
0161155
NGNGスレ違いなんだけど、私も一つだけ。
私は基本的に「使用頻度が高く機械的にできる」を支持したいなあ。
ソフトウェアの改善という、それまで「一から書き直したほうが早い」と
されてきた手のつけようのない難事業を、
ある程度機械的に処理できるようになったことが、リファクタリングの
第一のご利益だと思うから。
もちろん、リファクタリングの中には、それではすまない部分もあるけど。
0162Java厨
NGNGすまぬ。interfaceとclassで、型として何が違うというの？
実装があるかないかの違いだけで、
interfaceは型そのものじゃないか？
Smalltalkがわからんのでリンク先読んでも肝心なところがわからん。
いってみれば、classはvoid型たれ、ということ？
じゃあ、classってなに？
0163デフォルトの名無しさん
NGNGんでもって、変数宣言時にインターフェイス(の集合)を指定すれば静的型付になる。
この場合の型はクラスとは独立しているからプロトタイプベースでも可能でしょ？
0164152
NGNG作業であって、パターンそのものではないです。
しかし、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"に掲載されたカタログから推測しました。
0165デフォルトの名無しさん
NGNGあなたの質問は、いつも私の知りたいポイントを突いているなあ。
ということで、どうかどなたかお教えください。
今までの議論を自分なりに理解すると、
・型、インターフェース…そのオブジェクトにどのような操作が可能か
定義するもの。
・クラス…そのオブジェクトがどのような継承関係で成り立っているか、
ライブラリの中でどのような位置にあるかを示すもの。
なのでしょうか？
私もJava厨なので、この二つが別物というのは驚きだし、いまいち
実感が湧かない。
01661
NGNGいや，まぁ… なんというか
余計な事に突っこんですまんでした．
Fowlerの本読むとリファクタリングのカタログ的な面が強調され過ぎてて
ちょっと堅苦しいなぁと思ってたんです．
その後Kent BeckのTDD本読んだら「機械的に」や「使用頻度が高い」とか
はあまり関係なくて，リファクタリングという作業，リズムが重要だというか…
0167Java厨
NGNG>>152をもう一回読んで小便したら気がついたのだが、
classは動的に出来ること(メソッド)がどんどん変わってよい(Javaではできない)、
ということではないかと。
そのときそのときで、なにかのinterfaceの条件にあっていればよい、と。
しかし、それはいびつだなぁ。Aさんが小学生だったのが中学生になり、かつバスケの選手になる、
というのはあるが、全人類が小学生や中学生バスケ選手になることはないと思う。
うーん、やっぱりクラスって何？
0168デフォルトの名無しさん
NGNGもちろんアカデミシャンからは稚拙な議論なのだろうけれど、
自分がずっと興味があって、しかし仕事と直接の関わりがなくて手を出せなかった
分野を、何とか自分に理解できるレベルで話してもらえるというのは最高です。
皆さんどうもありがとう。
0169152
NGNG> その後Kent BeckのTDD本読んだら「機械的に」や「使用頻度が高い」とか
> はあまり関係なくて，リファクタリングという作業，リズムが重要だというか…
そうですね。Kent BeckはXPからもわかるように、開発プロジェクト全体の
手法のほうに着目してますから。
ところでプロトタイプベースでもリファクタリングみたいな作業は重要だと思いますが、
↓こんなのがありますね。
http://selfguru.sourceforge.net/
個人的にはC++やJavaのような「堅い」言語よりも、プロトタイプベース言語のほうが
Refactoringのカタログを充実させる要請が強いと思うのですが、どうでしょう？
オブジェクトをクラスではなくインスタンス単位でまとめていくために必要になる
「カン所」にうまく名前を付けて、多くのプログラマからそれらを集積して整理する
ことで、プログラマの能力をよりよく発揮させられると思うのですが。
0170デフォルトの名無しさん
NGNGその類(クラス)のオブジェクトが共通に使うものって事?
で、C++やJavaはクラスを型としても使ってしまっているから混乱するって事?
Smalltalkがクラスを型として使っていないってのは、オブジェクトが何のクラスに属するかは
きっちり決まっていて、クラスからオブジェクトを生成するけど、
オブジェクトをポイントする変数そのものには型が無いって事?
Java のインタフェースも思いっきりクラスの気がするんだけど。実装は持たないし
オブジェクトを作る元にもならないけど、継承もできるし、オブジェクトの分類を示すものには
違いないでしょう?
それでもやっぱり抽象データ型の変形に過ぎないのかな?
0171152
NGNG> というのはあるが、全人類が小学生や中学生バスケ選手になることはないと思う。
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があろうがなかろうが関係ないんじゃない？
という話です。
01721
NGNGなんか最近妙に賑わってるのがなんか怖いw
このスレ立てたのが，プロトタイプベースに関する日本語の資料がほとんど見つからなかった
という理由なんだけど，興味ある人/知ってる人はけっこういるみたいね．
俺もSelfとか使ってみたいんだけど… 初心者が簡単に手をつけられる状況じゃないよなぁ．
0174Java厨
NGNGinterfaceの適切な粒度とそれ中心で考えるというのは理解するし、普段から心がけている。
話はそれではなく、クラスの定義がどんどん変わると、
世界に散らばったインスタンス達も同様に変わってしまうわけで、
それは普通は変ではないかと。
個々のインスタンスが変身していくのはわかるけど、と。
こう考えると、クラスってなに？と。
クラスベースでクラスにこういうことやるのはおかしくない？と
0175デフォルトの名無しさん
NGNGクラス定義を動的に変えられることは、仕様の変更を伴うものばかりとは
限りません。メソッド名を変えずに、別のより性能の良いアルゴリズムを
採用したものに差し替えるとか、それこそバグの修正ということもありえます。
大事なのは、システム(アプリ)を停止せずにこれができるということで、
クラスのあるべき立場を危うくすることは目的ではないと思います。Smalltalk
にしても CLOS にしても、できるからといって、クラスの定義がどんどん
変わってゆくような設計は特殊な事情でもなければしないはずです。
0176デフォルトの名無しさん
NGNG>>173
Java の interface は、クラスの定義時に、設計者が
宣言しなければならないところが問題。
例えば、メソッド A と B と C を要求する interface I
があるとしよう。そしてクラス X は A も B も C も定義
している。しかしクラス X が interface I を implements
していなかったら I としては使えないわけだ。つまり、
クラスの作成者があらかじめあらゆる使われ方を考慮
しておかないといけない。でもこれは無理な話なわけで。
ここで動的型付け言語だとそもそもそういう宣言は必要なくて、
実行時に A B C というめそっどがあればよい。また、静的
型付け言語でも interface の後付けができる処理系が
あったはず。そういう機構があるなら、>>171 の言ってる
問題点は解決したと言ってもいいと思うよ。
0177デフォルトの名無しさん
NGNG>>152の
> だから、変更のし難さというのはクラスベースだからというわけではなく、
> むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。
> つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と
> 同一視したことによる縛り。
とうまく整合できないのですが、
よろしければ補足をいただけませんか？
0178デフォルトの名無しさん
NGNG実行中にプログラムを変える口を持つかどうかということではないだろうか。
0179デフォルトの名無しさん
NGNGinterface I をインターフェース継承して、Xをメンバに持つ新しいクラス
newXを作ってメソッドA,B,CをXに委譲すれば解決。
0180デフォルトの名無しさん
NGNG0181デフォルトの名無しさん
NGNGそれだと実行前に定義しておかなければならないという問題を全然解決していない。
0182152
NGNG私は>>175氏ではありませんが、たぶん彼が言いたいのは、
「納入したシステムが実行時に動的に自身のクラスを頻繁に変更するのは
特殊な場合だろう」
ということなのでは？
一方、私の>>152は実行時といっても開発における実行時の話であり、
クラスを変更するのはプログラマです。
というわけで、私としては>>175氏との間に意見の齟齬は無いと思っています。
で、私自身、>>175氏に同意します。
Smalltalkで「実行時に動的に自身のクラスを頻繁に変更する」のも可能では
ありますが、よほど強い要請がなければやりません。
ただ、それが可能であることは重要だと思います。
プロトタイプベースでも同様だと思います。
動的にdelegationを変更したりslotを変更するのは、それ自体が目的ではなく、
表現したい振舞いを簡潔かつ見通し良く記述するための手段に過ぎないわけで
そのためのプロトタイプベースです。
実現したい振舞いを可能にするための動的変更を最小のインパクトに抑えるのは
プロトタイプベースであれクラスベースであれ共通の指針だと思います。
この視点に立った上で、言語処理系自体が動的変更を標準の機能として認めていて
実際に簡潔な記述で動的変更が可能であることは強力な武器だと思っています。
0183厨
NGNG> 変更のし難さというのは
> 静的型の弊害であり、
> クラスをそのまま型として使うことの弊害
つまり、クラスが静的型だから動的に変えられないよう、と。
で
クラスを動的に変えるのは普通よくないよ。
ということなら、
クラスを静的に変えるときに、静的型うざいよう。
ということになると思うのですが
結局影響を受ける参照箇所は直さなきゃいけないんだから
かわらなくないですか?
0184デフォルトの名無しさん
NGNG> 結局影響を受ける参照箇所は直さなきゃいけないんだから
もっと具体的に言わないと議論のネタにならないと思われ。
0185デフォルトの名無しさん
NGNGことじゃね？
0186デフォルトの名無しさん
NGNGオブジェクトを動的に委譲でのみリンクしていく
言語だと規模が大きくなると設計とパフォーマンスの
両方ですぐに行き詰まると思う。
0187CLOS
NGNGやるけど、いざというときは Change-Class で変身できるし。
MOP つかえば抽象クラスやインターフェースも作れるよ！
0188デフォルトの名無しさん
NGNGクラスを動的に変えるのが良くないのは、ある程度仕様が固まってきてからでしょう。
開発初期にオブジェクトの振る舞いを動的に変更出来る事はメリットあると思うな。
私はシステム開発した事が無いので、的外れな事を言ってるかもしれないけど（一応
その周辺部で仕事はしてますが）。
この延長で、全く仕様が固まらない様な仕事、例えば研究者が全く新しい分野のソフト
ウェアを作ろうとしたら? 或は、仕様の変更に柔軟に対応しなくてはいけないシステム
だったら? ソフトウェア自身の速度よりも、ソフトウェアを開発するスピードが重要
だったら? そう言う場合は制約の少ない言語を選びたい人もいるのではないでしょうか?
逆に言えば、経理システムや在庫管理システム向きの言語ではないと思う。
スレの流れに沿ってなくてｽﾏｿ。
0189188
NGNG一応、Kansas/Nebraska と Yahoo! Store, 書き捨てのスクリプトを念頭に
置いてます。
あと、病院のシステムを開発するのにも向いてないと思います。
0190デフォルトの名無しさん
NGNG0191デフォルトの名無しさん
NGNGそれが問題となるのは、あなたが適用すべき言語の選択を間違った時ではないでしょうか。
それは置いておいても、Self は積極的な最適化で結構速いらしいですし、同じ動的言語の
Common Lisp もネイティブコードにコンパイルする事でかなり速いです。
0192デフォルトの名無しさん
NGNGうーむ、Java にはリフレクションというものがあって、クラス情報の分からない
インスタンスのメソッドやフィールドにアクセスできるようになっている。
しかし、使うのは最低限にしろという原則がある。処理が重いから。
（どのぐらい重いのかは知らないけど）
動的な型付けの言語って、すべての局面でリフレクションをやっているような
ものじゃないのかな？やっぱりどうしても比較すれば重くなるでしょ？
（このリフレクションという言葉が、本来の意味から大きく外れているのを知った
のは最近…）
0193CLOS
NGNG考えつかないのかな？特に漏れなんてマルチメソッドディスパッチのおかげ
で最悪メソッドコール毎にメソッドの探索が必要になっちゃうけどメソッド
キャッシュやオプショナルな型指定のおかげでそこそこがんがれる。
まぁ、漏れも性能が大事な部分では「オプションで」型指定できたり、
メソッド内では引数の型指定で積極的な最適化が可能だったりと完全に
動的言語ってわけじゃないけどナー。普段は動的で、必要なときに
型を使うわけだ。ウマー。
0194CLOS
NGNGクラスベースよりプロトタイプベースのほうが逝けてるゼ！とクラスベース vs
プロトタイプベースの争いがあったんで完全にスレ違いってわけでもないのだ。
…と言い訳してみる。
0195デフォルトの名無しさん
NGNGJavaのリフレクションが重いというのは只の伝説です。
今のJVMなら、普通のメソッド呼び出しと殆ど変わりません。EJBなんてリフレクションだらけ。
最低限にしるというのは、コードの解り易さの為。
0196デフォルトの名無しさん
NGNG0197デフォルトの名無しさん
NGNG0198192
NGNGすると、こんな感じ？
Java = 静的な言語だけど、必要に応じて動的にも使える。
CLOS = 動的な言語だけど、必要に応じて静的にも使える。
最近は Java でも、ほとんどのコードはパフォーマンスを気にせずに書いて、
ロジックが完成してからパフォーマンス測定して、ボトルネックになってる
部分だけチューニング、というやり方が増えてきた。
そうすると、CLOS のやり方のほうが便利かも…。
>>195
ああ、そうなんだ！JSP のタグリブとかも、リフレクションの塊なわけで、
「こんなんで良いのかな？」と思ってたんだ。
昔の話だったのね。安心しますた。
0199デフォルトの名無しさん
NGNG重くないといっても通常のに比べたら数倍はやっぱりかかる。
まあ昔みたいに何十倍もかからなくはなってるが。
0200CLOS
NGNGLisp マシンの頃からそうだった気がする。基本的にはさっさっと書いて、
プロファイリングして、型を間違ったらヤバそうなところとかボトルネックに
あたりをつけて型指定を入れるスタイルだな。（性能＋型チェックのため）
CLOS 自体は動的な側面が強く、オーバーヘッドを嫌った連中がプロトタイプベース
＋制約ベースの最適化なんてのを考えたりもしたわけだ。最近だと型にかぶれてたり
型推論を装備しちゃた変種まで表れて動的言語とはひとくくりにはできないがな…。
0201デフォルトの名無しさん
NGNGJava 以外の言語知らないのかしらん?
Sather ではとか言ってさらさらっとコードでも書いてくれたら ｶｺｲｲ のに。比較対象
が Java 以外にもあると良いな。
0202デフォルトの名無しさん
NGNG満たされるのはあなたの衒学趣味くらいではないですか？
0203デフォルトの名無しさん
NGNGくらいしか知らんし。OCaml でオブジェクト指向している例は見たことが無いし、Eiffel
なら Sather の方が面白そうかなと。後は Strongtalk とか? 色んな言語と比較した方が、
それぞれの関係性も理解出来ると思ったんだが。
0204デフォルトの名無しさん
NGNG出てくる必要があるのは、Javaにはない機能や概念に触れた内容のレスである思います。
あなたの真の欲求は、「マイナー言語知識自慢スレ」を立ててそこで満たしてください。
もちろん、このスレで知識を生かしたこのスレの趣旨にあう良レスをしてくれることはみんな歓迎するでしょう。
0205デフォルトの名無しさん
NGNG機能は何かとか、そういう視点があっても良いと思うんだよね。マイナー言語と片付けるのも
反対はしないけど、それを言ったらプロトタイプベース言語はどうなんだろう。必要な言語に
だけ触れていれば良いの?
0206デフォルトの名無しさん
NGNG私が Java の話しかしないのは、恥ずかしながら「それしか知らない」から。
言語が備えるべき機能についても、Java の機能しか知らないから、他のことが
言えないんす。
このスレに来てるのは、必ずしも Java に満足していなくて、別の可能性を
知りたいからなんす。プロトタイプベースには昔から興味があったし。
設計方面に片寄った話をするのは、実際、そこで困っているから。Java 以外の
可能性に触れることで、それを解決できたら、と思ってます。
あわよくば、Java での仕事に、その言語の考え方を取り入れられたらいいなあ。
デザインパターンやリファクタリングが Smalltalk から取り入れられたように。
まあ、Java な人がみんな、私みたいな厨房というわけではないと思いますが。
0207デフォルトの名無しさん
NGNG他を自主的に覚えようとしない訳だしな・・。
ここは206の疑問に答えるスレでもないし
とりあえずSmalltalkでも勉強したら？
0208デフォルトの名無しさん
NGNG0209デフォルトの名無しさん
NGNG0210デフォルトの名無しさん
NGNG0211デフォルトの名無しさん
NGNG今やるなら io が結構良さげな感じがするんだけど、こういう便利な使い方があるぜ
ってのがあったら教えて欲しい。
0212デフォルトの名無しさん
NGNG0213デフォルトの名無しさん
NGNG0214デフォルトの名無しさん
NGNGアカデミックな事にはあまり興味無い実務屋が多いんでしょう
仕事でJavaと付き合ってるのでプライベートでは他の言語とお付き合いしたいという
私みたいなのもいるけど
ちょっと調べたけどJavaScriptってかっこいいなあ。
結構ちゃんとしたプロトタイプベースのOOPLなのね。
私にとってはSmalltalk並にヒット。
0215デフォルトの名無しさん
NGNG漏れはJavaScriptでクラスを使いたいYo!
0216デフォルトの名無しさん
NGNG0217デフォルトの名無しさん
NGNG0218デフォルトの名無しさん
NGNG0219デフォルトの名無しさん
NGNGhttp://squab.no-ip.com:8080/wiki/818
> (Traitsを) JavaScript ではまんまクラスと呼んでいる。
JavaScriptでクラスなんて呼ばれるものはあったっけ？
コンストラクタのこと？
確かに、
var a = new String("hoge");
alert(a instanceof String); //true と表示。
という動作を見ると、一見、クラスっぽい。
0220デフォルトの名無しさん
NGNG今時C++つついてる奴も結構趣味に走ってると思うが。特にtemplate方面。
0221デフォルトの名無しさん
NGNG趣味だけど実益兼ねているでしょ、アレは。
boost、Loki あたりはウチの会社じゃ普通に使ってるし。
0222デフォルトの名無しさん
NGNGあんなの使ったら強制デスマーチですが何か？
0223デフォルトの名無しさん
NGNG0224デフォルトの名無しさん
NGNG会社じゃ低レベルな奴が足引っ張るみたいだな。
勘弁してほしい。
0225デフォルトの名無しさん
NGNG> 会社じゃ低レベルな奴が足引っ張るみたいだな。
むしろ自分が使いたい言語の利点をきちんと説得できないのを恥じるべし
0226デフォルトの名無しさん
NGNGそれはいくらなんでもスキル低すぎだろ。
0227デフォルトの名無しさん
NGNGいや俺会社員じゃないし。
話し聞いてると会社がそういうとこらしいのが嫌だなってこと。
0228デフォルトの名無しさん
NGNG0229デフォルトの名無しさん
NGNG実装モデルには当然クラスは出てこないんだろうけど
基本的にオブジェクトの発見がメインで、ドメインモデルでもクラスは見つけないのかな。
0230デフォルトの名無しさん
NGNG0231デフォルトの名無しさん
NGNGhttp://www.radiumsoftware.com/0312.html#031250
こういうのどうよ？
クラスの意味論？とかの観点を語れそうじゃね？
0232デフォルトの名無しさん
NGNGhttp://www.radiumsoftware.com/0312.html#031205
0233デフォルトの名無しさん
NGNGprototypeなんてのを持ち込むくらいなら、素直にclassを認めた方がいいかなと
思ったり。
0234デフォルトの名無しさん
NGNGクラスなんて本質的に必要なものじゃないし。
Ruby みたいに、クラスのインスタンスだけど後からあれこれ出来ますってのが、厨避け
には良かったのかもしれない。
0235デフォルトの名無しさん
NGNGプロトタイプはクラスとしても使える、という話じゃなくて？
0236デフォルトの名無しさん
NGNGそれをメモリ効率とかの観点から、prototypeを導入したわけだ。
それなら雛型としてのclassを認めた方が、むしろシンプルかなと思った。
0237デフォルトの名無しさん
NGNG1,2 行目と 3 行目の繋がりが良く分からないな。「classを認める」というのは具体的に何を
イメージされてるのですか。
0238デフォルトの名無しさん
NGNGプロトタイプベースでも多くの場合、クラスとインスタンスの関係に近い
オブジェクトをいろいろ用意して使うことになるよね。
それは、暗黙のうちにクラス的なオブジェクトとインスタンス的なオブジェクトを
使い分けてるってことで、なら割り切って、他にも利点のあるクラスベースの方が
いいんじゃないかなぁと思った。
なんというか、プロトタイプは中途半端な気がする。やるならプロトタイプも
なくしてしまえ! と。(w
あー思いつきで適当に書きすぎた。
0239デフォルトの名無しさん
NGNGclass にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
ところで prototype をなくす利点ってどのへん？
派生先が派生元の変更に影響されなくなることくらいかな…
0240デフォルトの名無しさん
NGNGよく使いそうな機能は言語のコアに最初から組み込んでおくべきなんだって考えの人も
居るみたいね。>>232 のリンク先の論文とか。
0241デフォルトの名無しさん
NGNGプログラム=データ構造+アルゴリズムという観点で見ると、
なにか重要な示唆が含まれているような気もする。
0242デフォルトの名無しさん
NGNG>なら割り切って、他にも利点のあるクラスベース
ここはトレードオフなんだよね。割り切って切り捨てられてしまったものが
結構便利だったりする。対象領域によってはクラス化しない方がシンプルな
場合も多いだろうし。
0243デフォルトの名無しさん
NGNG> class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
そんなのclassの実装次第でしょ。
0244デフォルトの名無しさん
NGNGそれならそれを prototype と呼んでも良いわけだ。
よし、この FOO 言語のクラスは従来のクラスにあった制限を一切取っ払った実装にしよう。
ついでに名前も変えて prototype と呼ぼう。これで BAR 言語で出来なかったこんな事や
あんな事も出来るようになるぞ。
0245デフォルトの名無しさん
NGNGということ自体は全然構わないんだが、
グローバルにしたくないものをグローバルにする必要があったり
メソッドの追加が煩雑だったりするのがかなわん
実用上大問題だと思うんだがどうよ？
0246デフォルトの名無しさん
NGNG> ついでに名前も変えて prototype と呼ぼう。
そのFOO言語のclassがclassというよりむしろprototypeであることを
ちゃんと理由を付けて説明できるのならね。
0247デフォルトの名無しさん
NGNG> 型＝インスタンス
> ということ自体は全然構わないんだが、
誰がそんな事を言っているのですか？
このスレでは該当する者はいないようですが・・・
0248デフォルトの名無しさん
NGNG実装次第でどうとでもなるなら、名前付けにも意味は無いですよねって事なんだけど。
0249デフォルトの名無しさん
NGNGとりあえず>>94読め。
0250デフォルトの名無しさん
NGNGそれを読むべきなのは >>243 だろうね。クラスの制約の話をしていて、実装次第と
いう答えはどうかと。
0251デフォルトの名無しさん
NGNGおいおい、>>94に書いてあるのは、インスタンス生成機能をどこに配置するかという問題で、
それはクラスへの制約ではなくインスタンスへの制約なのだが。
クラスが一般のインスタンスと同様の機能を持つクラスベースOOPLだって存在するし、
そのOOPLでのクラスはプロトタイプではなく、あくまでクラスだ。
よってクラスへの制約は実装次第ということで間違ってはいない。
0252デフォルトの名無しさん
NGNGクラスへの制約なんて話は今まで出てきてないけど、インスタンス生成に関する制約
って事かな。
だいたい、>>94 はインスタンス生成機能だけじゃなく、オブジェクトの分類にも
触れていると思うけど。その上で、モデリングの違いで使い分ければ良いとも読める。
0253デフォルトの名無しさん
NGNG>それはクラスへの制約ではなくインスタンスへの制約なのだが。
ｽﾏｿ。ちゃんと読んでなかった。で、クラスへの制約って何?
0254デフォルトの名無しさん
NGNGそれは>>239に聞かないとわからん罠
0255デフォルトの名無しさん
NGNG概念なんだろうね。自分で参照したレスもちゃんと読んでないみたいだし。
でももう良いよ、終わりにしよう。説明するのも疲れた。
025694=249
NGNG> class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
これがクラスへの制約でなくて何だと言うのだろうか・・・
0257デフォルトの名無しさん
NGNG>>255
>でももう良いよ、終わりにしよう。説明するのも疲れた。
説明がちゃんとできてないし、話もお互い通じてないな
おまえら、ろくな定義もされてないあやふやな概念を
一方通行にただ垂れ流してるだけだ
それで余計に疲れるんだろ
0258デフォルトの名無しさん
NGNG02591
NGNGはRubyでSelfライクを実現，ですが
こちらはJavaScriptライク
http://mput.dip.jp/?date=20030912
特異メソッド/クラス定義 凄い便利だよな．楽しいよな
Rubyが完全にプロトタイプベースだったら…
0260239
NGNGclass にしかできないことっていうのは、 instance とか subclass の生成あたり。
あとは処理系の柔軟性のなさに応じて、 method や property の追加・削除とか、superclass 変更とか。
class にはできないことのほうは、確かに柔軟な言語にはないかも。
普通の object として複製したり、書き換えたり渡したりってあたりを想定してたけど。
充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。
subclass 作ったり method 書き換えたりはしても、 class じゃない instance は作らないっていう。
で、これを簡潔にしたのが prototype-based OOP だと思う。
もう class なんて概念もいらなくなって、世界には object だけあればいい、っていう。
0261デフォルトの名無しさん
NGNG> 充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。
整数とかはどうする？
整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、
クラスとインスタンスの区別があったほうがずっとシンプルにならない？
クラスの有り無しは目的ではなくて手段にすぎないんだから、
「クラスを無くすには」「クラスを導入するには」ってのは
処理系実装以外のシチュエーションではナンセンスだと思う。
0262238
NGNG>>239
classとobjectを区別しないprototypeでも，実際に使うと自然に
classとinstance的なものを考えるようになる．
だから，classとinstanceは本質的に違うものであって，それを
prototype-basedな言語は無理矢理まとめてしまった…とも考えられる．
> ところで prototype をなくす利点ってどのへん？
> 派生先が派生元の変更に影響されなくなることくらいかな…
これは結構大きい．派生元の影響を受けるから，自然にclass, instanceの
を区別する使い方をしてしまうんだと思う．
シンプル，という観点から見れば，prototypeすらないのが一番素直．
ある程度メモリ効率とかを気にして，classやprototypeが考案されたと．
そんな中で，prototype-basedは，やっぱりちょっと中途半端な気がする．
0263デフォルトの名無しさん
NGNGプロトタイプすらないってどういうのを想像しているの？
オブジェクトの拡張はどうやってやるんでしょうか…
0264デフォルトの名無しさん
NGNG0265デフォルトの名無しさん
NGNG> 整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、
> クラスとインスタンスの区別があったほうがずっとシンプルにならない？
あんまり差が思いつかない…どんなとこが違いそう？
>>262
> だから，classとinstanceは本質的に違うものであって，それを
> prototype-basedな言語は無理矢理まとめてしまった…とも考えられる．
役割分担するにしても、厳格に分けないほうがやりやすいと思う。
それぞれの object を class とか instance って呼んでもいいけど、
いつでも役割交代させたり、一人二役させたりできる…っていう。
> シンプル，という観点から見れば，prototypeすらないのが一番素直．
> ある程度メモリ効率とかを気にして，classやprototypeが考案されたと．
効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。
使う library 切り替えるときとか、関係する object 全部書き換えるのは大変だし。
それに、全部複製して持たせちゃうような method も、簡単に書けるよね。
どっちを default にするかの違いでしかないと思う。
両方用意するほうが親切だろうけど。
0267デフォルトの名無しさん
NGNG影響し合うするのは良くないと思うけどなぁ．
0268デフォルトの名無しさん
NGNGその、「良くないと思う」レベルが
classベースと、
prototypeベースと、
なんも無しと、
で違うだけだよ。
0269デフォルトの名無しさん
NGNG影響し合うのはprototype-basedだけじゃない?
0271デフォルトの名無しさん
NGNG> クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑
そういう言語もアリだと思うけど。
instance creationした瞬間のclassがそのobjectのclassってことでしょ？
0272デフォルトの名無しさん
NGNG出来たとしても，>>271のようになるのが自然だと思う．
0273デフォルトの名無しさん
NGNG> 出来たとしても，>>271のようになるのが自然だと思う．
そんなこたーない。普通はクラスを変更したらインスタンスも変更される。
0274デフォルトの名無しさん
NGNG0275デフォルトの名無しさん
NGNG普通はって、「出来たとしても」という条件を満たした上での「普通は」でしょ。
文脈からいって。
0276デフォルトの名無しさん
NGNG0277デフォルトの名無しさん
NGNGを説明してくれませんか？
0278デフォルトの名無しさん
NGNGそれはそうなんだけど、普通はって言うほどサンプルが無い気がして。
メソッドサーチの時にクラスをルックアップするのが普通の実装だから、クラスを変更
したらインスタンスも変更されるでしょうって事かな。
0279デフォルトの名無しさん
NGNG0280デフォルトの名無しさん
NGNG0281デフォルトの名無しさん
NGNG実務での使用だと利点は無い。
なのでみんなクラスベースを使ってる。
0282デフォルトの名無しさん
NGNGrapid prototyping的に、モノを動かしながら要求分析する時とか。
0283デフォルトの名無しさん
NGNG0284デフォルトの名無しさん
NGNGいくつかオブジェクトは出てきているけど
どれとどれが似ていて、どれとどれがどう関連していて
どのオブジェクトがどんな情報を持っているのかはっきりしていない状況では、
クラスを通して間接的にオブジェクトの振舞いを変えていくよりも、
目の前にあるオブジェクトを直接イジれたほうがやりやすい。
特にユーザーインターフェースデザインでは効果的。
クラスベースよりもずっとオブジェクトを直接触っている感覚があるし、
お客さんにもわかりやすい。
そうやって、お互いの理解を深めた上でクラスベースの分析設計に入ればいい。
これ以上は自分で体験してもらわないことには、言葉で伝えるのは難しい。
Smalltalk上にプロトタイプベースな環境を構築したものはいくつかあるから、
どれか試してみるといい。
まあ、今でも使えるものということになるとSqueakが一番手頃かな。
ちょっとクラスベースの匂いが残ってるけど。
0285デフォルトの名無しさん
NGNG動かす前にやったらダメかね。
0286デフォルトの名無しさん
NGNG紙芝居でもいいから動くものが目の前にあったほうが、
お互いに自分の考えを言葉にしやすいわな。
0287デフォルトの名無しさん
NGNG・強い型付けと組み合わせて、最適化が図れる。
・クラスに着目して設計が可能なので、クラスの個数＞＞インスタンスの個数であれば
設計やコード読むのが楽になることがある。
って程度じゃない？でもまあ後者はとても強い利点だと思う。
自由度を制限することによって得られるものもあると思う。主観ばかりでスマソ。
0288デフォルトの名無しさん
NGNGこれなんてプロトタイプ/クラスベース関係ないんじゃない？
デザインの変更にコードをいぢるのかと。
みんなが納得のプロトタイプ利点の実例ってないですか？
0289デフォルトの名無しさん
NGNG> これなんてプロトタイプ/クラスベース関係ないんじゃない？
とても関係ある。実際にやってみれば大きな違いがわかると思う。
> デザインの変更にコードをいぢるのかと。
当然いじるでしょ、ボタンの位置を1ピクセル動かすとかでない限り。
どんな情報をどのような時にどのように見せるのか、
これを変えようとしたらコードをいじることになるのは当然でしょ。
その時、目の前にあるGUIが生きたオブジェクトになっていて、
動かしながらそのオブジェクトのコードや変数を直接いじれる。
生きたオブジェクトをプロトタイプからコピってきて、生きたGUIの上に置ける。
そして置いたオブジェクトに変数を定義したりメソッド変えたり、
この直接オブジェクトを作り上げていく感覚はクラスベースではなかなか出てこない。
Smalltalkでさえ、クラスをいじってる限りは間接的な感じがある。
0290デフォルトの名無しさん
NGNG>どんな情報をどのような時にどのように見せるのか、
>これを変えようとしたらコードをいじることになるのは当然でしょ。
別に当然じゃないでしょ。
UIの情報をコードと分けてて後から自由にいじれる
クラスベースのシステムだってあるよ。
0291デフォルトの名無しさん
NGNG> UIの情報をコードと分けてて後から自由にいじれる
> クラスベースのシステムだってあるよ。
で、そのUIの情報とやらには何が入るわけ？
GUIってのはViewだけじゃないよ。
MVCで言えば、MVC全部でUIを構成するんだよ。
それを動かして見せようとしたら、M同士の相互関係も必要だよ。
当然、何らかの計算が必要なら、それを実装するんだよ。
それが>>289で言った
> どんな情報をどのような時にどのように見せるのか、
ということ。
0292デフォルトの名無しさん
NGNGMVC全部って言ったらそれはもうシステム全体じゃん。
0293デフォルトの名無しさん
NGNG0294デフォルトの名無しさん
NGNG> GUIのデザインっていったらViewだけを指すと思うけど。
おいおい、Controllerまで外す香具師は初めてだぞ。
> MVC全部って言ったらそれはもうシステム全体じゃん。
そんなこたーない。
何を表示するか、Modelの吟味無しにマトモなUIデザインができるわけないじゃん。
ミドルティアっぽい部分についてもバックエンドとかパフォーマンスとか頑健性とか
エラー処理とかロギングとか、GUI用のプロトタイピングでは無視していいファクター
は沢山ある。オモチャみたいなロジックでいいから、動かすことに意味がある。
ちょっと刺がある言い方するけど、UIデザインを甘く見てるんじゃない？
ボタンの位置とかフォントとか色とかだけがUIデザインじゃないよ。
そういうのはあくまでUIデザインの結果にすぎない。
0295デフォルトの名無しさん
NGNGシステムのデザインだろ。
0296デフォルトの名無しさん
NGNGやめとけ
フォーム描きがUIデザインだと思ってる馬鹿には何言っても無駄
しかしコントローラ抜きのUIデザイン藁た
0297デフォルトの名無しさん
NGNG> システムのデザインだろ。
システムデザインにバックエンドもパフォーマンスも頑健性もエラー処理も不要ならば
君の言う通りだ。
しかし、画面上で関連するModel間の関係だけでシステムデザインができるほど
世の中甘くないんだよ。
0298デフォルトの名無しさん
NGNG0299デフォルトの名無しさん
NGNG>ボタンの位置とかフォントとか色とかだけがUIデザインじゃないよ。
>そういうのはあくまでUIデザインの結果にすぎない。
甘く見るも何もUIデザインなんてかなり地道な作業だとおもうけど。
プログラマというよりほとんどオペレーターというか。
いや毎日そんなんばっかりでなんか愚痴りたくなって。すんまそん。
0300デフォルトの名無しさん
NGNG本格的に開発に入って他言語に置き換えるんだったら、
始めからクラスベースの言語で書いた方がイイと思うんだが。
0301300
NGNGUI 専門の部署から回ってくるもんじゃないの？
うちの会社じゃそうしてるけど。
0302デフォルトの名無しさん
NGNG0303デフォルトの名無しさん
NGNGプロトタイプを2,3回作って「ハイ、オッケー」ならいいけどね、
実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。
特に、プロトタイプが必要になるような探求的なプロジェクトではね。
そういう時には、プロトタイプベースのほうがその場で手早く手直しして見せられる。
その場で手直しして見せることで、お客さんも自分が何を必要としているのかが
だんだん見えてくる。
もちろんクラスベースでもできないことはないけど、プロトタイプベースのハンディさ
はなかなか得られない。
あと、プロトタイプで使ったコードを本番に使い回すのはよくないと思うよ。
同じ言語/環境を使うにしても、最初から書き直したほうがいい。
考慮すべきファクターが全く違うから。
0304300
NGNG> 実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。
無論、プロジェクトが終わるまで何度も打ち合せはするだろうけど、
なるべく短期間で客の要求を的確に割り出すのが仕事じゃないのか。
ほとんどの場合、ヒアリングで解決することだし。
> あと、プロトタイプで使ったコードを本番に使い回すのはよくないと思うよ。
そりゃまぁ適当に書いたコードを使い回したりするのはマズいだろうけど、
キチンとしたコードなら一向に構わないと思うんだけど。具体例きぼんぬ。
抽象的な話が多すぎて利点が良く分からん。
具体的にどんな仕事でどういう風に使えば、どういう利点があるの？
0305デフォルトの名無しさん
NGNG非常に稀な例だからなぁ．
0306デフォルトの名無しさん
NGNGなんかいやな仕事だな。
いやな客にすばやく対応できるとかじゃなく
もっと明るい利点はないですか？
0307デフォルトの名無しさん
NGNGクラスベースで，オブジェクトへの動的なメンバ追加を許す言語はある(はず)．
メンバの動的変更はプロトタイプベースの特権ではない．
03081
NGNGまずクラスベースでの具体例だせよ…
クラスあるとこいういう風に綺麗に作れるけど，
プロトタイプベースじゃこうはいかないだろ？
と．
0309デフォルトの名無しさん
NGNGやってることと同じ内容で言い争ってる？
問題点はもう少し整理しないと。
0310デフォルトの名無しさん
NGNGプロトタイプベースでもクラスベースでも同じ書き方ができるんなら，
実行効率や型チェックの面で圧倒的にクラスベースの方がいい．
問題は，プロトタイプベースでうまく書けるが，クラスベースではうまく書けない
例がどの程度存在するか，そしてそれは必要なのか，という点．
0311デフォルトの名無しさん
NGNG> なるべく短期間で客の要求を的確に割り出すのが仕事じゃないのか。
そのためのラピッドプロトタイピング。
> ほとんどの場合、ヒアリングで解決することだし。
十分に枯れたドメインなら言葉だけでいいかもしれんけどね・・・
プロトタイプを動かしながらお客さんの指示に従って変えていくヒアリングもアリだよ。
> そりゃまぁ適当に書いたコードを使い回したりするのはマズいだろうけど、
> キチンとしたコードなら一向に構わないと思うんだけど。具体例きぼんぬ。
プロトタイピングはキチンとしたコードを書くのが目的ではなくて、
お客さんの要求を引き出すために必要十分に動けばいい。
むしろエラー処理やスケーラビリティがキチンとしたコードを書くために
プロトタイプ作成が遅くなるのでは本末転倒になりかねない。
それよりも、目の前にいるお客さんに一秒でも早く動きを見せたほうがいい。
もちろん本番のコードはキチンと書く。当然だよね。
具体例は、俺が実際に経験したプロジェクトを具体的に書くと
狭い業界だからお客さんや俺自身が特定されかねないんで、勘弁。
0312デフォルトの名無しさん
NGNG0313デフォルトの名無しさん
NGNG0314デフォルトの名無しさん
NGNG0315デフォルトの名無しさん
NGNG0316デフォルトの名無しさん
NGNG大抵の実装でオブジェクトがスロット付きであって、メソッをド含むスロットの追加・削除が
動的に可能だということの方が支配的だと思うな。
0317デフォルトの名無しさん
NGNG良い事言った！
俺もそう思うよ。
0318デフォルトの名無しさん
NGNG同意．ただ，>>307をどう見るかですな．
0319デフォルトの名無しさん
NGNG言語があっても良いでしょうね。Ruby みたいな。
0320デフォルトの名無しさん
NGNG0321デフォルトの名無しさん
NGNG（gcc / g++ でもフィールドを陽に指定する初期化リストなんかが使えるけど）。
ハイブリッドはアリだと思うなあ。フレームに対するメソッドインボケーションは
NewtonScript / Self 式、そうでない、構造体に対しては C++ 式とか。
純粋 prototype ベース（フレーム理論ベース）言語だと、
Complex とか Rect のような小さな構造でオーバーヘッドが大き過ぎ（やる気でない）。
0322デフォルトの名無しさん
NGNG0323デフォルトの名無しさん
NGNGやめろ．荒れる．
0324デフォルトの名無しさん
NGNG0325デフォルトの名無しさん
NGNG漏れはクラスがあってもなくても、どっちでもいいけど、
クラス無しでオブジェクトを記述する方法はあったほうがいい派。
0326デフォルトの名無しさん
NGNG結局何も無いだろ？
0327デフォルトの名無しさん
NGNGだから有る無しじゃないんだってば、おとっつぁん。
0328デフォルトの名無しさん
NGNG「出来ること/出来ないこと」という論点では、
ほとんどのプログラミング言語はチューリング機械相当ということで
同等だ罠。
0329デフォルトの名無しさん
NGNG変更出来れば、より柔軟にメッセージを送受信出来るので嬉しい。
0330デフォルトの名無しさん
NGNGシームレスに落としこめるというものがある。
その辺り、プロトタイプベース言語やLispなどでは、
プログラマの経験則に多くを負っている。開発手法との
関連付けも弱い。
分析、設計、実装を繰り返すスパイラルな開発においては、
個人的にはプロトタイプベース言語の方が向いているように
思うが、Javaにはそこでもかなりのセオリーや実績がある。
開発手法がプログラミング言語非依存なものであることから
考えて、プロトタイプベース言語が開発のサイクルを回す上で
優れているのなら、実績があってもいいはず。Java派の
人の言う「具体例」とはこういうことだと思う。
まあ言語自体がマイナーだから具体例なんてないけどね（ｗ
俺はEmacsが好きだし、プロトタイプ言語にも活躍の場は
当然あると思うけど、それは優れたプログラマが小人数で
開発するケースにしか使えないと思う。
なお、使い捨てのデモアプリケーションを作るという意味での
プロトタイプ言語はここでは考えていません。
0331デフォルトの名無しさん
NGNG(プロトタイプベースのほうが柔軟にはしやすいのだろうけど)
じゃあ、あとはどっちを使うかは個々人の流儀の問題で、ただの好き好きに過ぎないって事ですか?
世の中でクラスベースが主流なのは何故?
処理系を実装しやすいのか? 静的な型チェックを厳密にできるからか? 単なる歴史的な経緯か?
世の中をclassifyしたがる人間の性か?
0332デフォルトの名無しさん
NGNG理想的な water fall で、固まった設計を実装するだけなら、静的な class-based のほうが強そう。
この場合、設計担当の人向きかな、とか。
0333デフォルトの名無しさん
NGNG世の中でクラスベースが主流なのは何故?
たまたま大手のソフトウェアベンダが採用したっていう
偶然的理由によるところも大きいんじゃないの？
>>332
開発方法論は言語ニュートラルなものとして作られてるけど
その実はかなり関係してるような印象を受けてる。
最近のものは殆どといっていい程、Java、もしくはC(オプソ？)を
想定したものばかりに見えるけど。。。
0334デフォルトの名無しさん
NGNGプロトタイプベースの利点も分からないのに、クラスベースではこうやる、
なんて出せるわけないだろ。
>>332
>理想的なwaterfallで、固まった設計を実装するだけなら、
>静的なclass-basedのほうが強そう。
クラスベースでwaterfallじゃない開発スタイルも存在すると思うんだけど。
>>>333が言うように、JavaとかCを想定したものが多いけどね。
クラスベースの方が直感的で分かりやすいからじゃないかな。
>>1はお怒りのようだからあんまり言いたくないけど、具体例が出てこないから
プロトタイプベースの言語や、開発スタイルがどういうモノなのかピンと来ないし。
0335333
NGNGprototype-based言語が有用だとJava派の人に対して主張するなら、
具体的な事例はまだないので、その代りに具体的な開発のシナリオを
出す必要があると思うね。開発方法論のセオリーも含めてさ。
言語だけ純粋に見て、その審美性だけで判断するようなことをしても
現実には全然訴えかけるものがないよ。美的観点だけで普及するなら
関数型言語がとっくに広まってるだろうし。
0336デフォルトの名無しさん
NGNG> prototype-based言語が有用だとJava派の人に対して主張するなら、
> 具体的な事例はまだないので、
をい、>>282さんがあれだけ丁寧に・・・>>332さんも同じ主旨の事を言ってるが、
両方無視かいな。
そもそもJava派って何なんだよ。Java以外のクラスベースはカヤの外かいな。
動的型付クラスベース派はどうすりゃいいんだよ(藁
0337デフォルトの名無しさん
NGNG具体的な例が(ry…って意見がいくつも出てるんだから、十分な情報じゃないんだろ。
0338デフォルトの名無しさん
NGNG言語の実践的な有用性については、大手ベンダーがその環境向けの標準開発環境として
採用するかどうかということだけが問題だけなんで、このスレ的にはどうだろうか。。
ってのは333で既出か。
WEB 方面では JavaScript の他に Macromedia Flash の ActionScript でも prototype.__proto__ による
プロトタイプ継承が使われてますね(ECMA Script準拠なんで当然だけど)。
0339デフォルトの名無しさん
NGNG既出だがECMAScriptには__proto__なんてないし、ActionScriptでも6.0から
__proto__は非推奨属性だしそもそも最近のActionScriptはクラス指向だし。。。
03401
NGNG多分このスレに書き込んでいるほとんどの人はプロトタイプベースOOPL
を使った開発なんてまともにやったことないでしょう．(私も含めて)
Googleでちょっと検索してみればわかると思うけど，ECMAScript以外は
解説サイトすらなかなか見つからない．見つかったら是非教えて欲しい．
そんな状況で圧倒的多数のクラスベース派がプロトタイプベースの明確な
利点がわかる具体例を示せなんて言ってたって時間の無駄だと思う．
>プロトタイプベースの言語や、開発スタイルがどういうモノなのかピンと来ないし。
それはそうでしょう．私も知りたい．
資料もないし，経験者も少ないし．
自分で触ってみるしかないですよ．
触ってみてこれはいいんじゃないかって思ったり
やっぱり使えないっと思うことがあるなら，
そういった情報を共有しようじゃないですか．
0341デフォルトの名無しさん
NGNG0342デフォルトの名無しさん
NGNG一応立派な実用例ではあると思う。
0343デフォルトの名無しさん
NGNG>それは優れたプログラマが小人数で
>開発するケースにしか使えないと思う。
それで良いんじゃないの?
使い道が分からない人間が無理に使う必要はないでしょ。
>>335
>prototype-based言語が有用だとJava派の人に対して主張するなら、
どちらかというと、Java 派の人にはどこか他所に行って欲しい。
というか過去レス嫁。審美性とか言っちゃって痛杉。
0344デフォルトの名無しさん
NGNG0345デフォルトの名無しさん
NGNGどっか行けと言いたいだけ。
0346デフォルトの名無しさん
NGNG0347デフォルトの名無しさん
NGNGクラスマンセーの人に押しつけもせず、クラスがないデメリットも含めて
冷静に語り合うスレでよいと思われ。
0348デフォルトの名無しさん
NGNG処理系の一つも自分で動かしてみようという気はないのか?
自分の疑問に思ったところを他の言語で実装し直してみれば立派な具体例だろう。
その言語はプロトタイプベースである必要も無い。
0349デフォルトの名無しさん
NGNG実際にやってみて「別にクラスベースでいいじゃん」と思っただけだが。
0350デフォルトの名無しさん
NGNGじゃぁクラスベースで良いんじゃない?
迷わず逝けよ。
0351デフォルトの名無しさん
NGNGどんな疑問ですか？
煽りだけど、まじめに答えてくれればなにかのネタになるかも。
0352デフォルトの名無しさん
NGNGどっかで落とせませんか？
0353デフォルトの名無しさん
NGNG0354デフォルトの名無しさん
NGNG古いし、動かしてみてないけど。他の Scheme リポジトリも見てみて。
ttp://ftp.cs.indiana.edu/pub/scheme-repository/imp/
0355352
NGNGこっから落とせた
http://www.cs.indiana.edu/scheme-repository/imp.html
03571
NGNGスロットっていうと名前で参照できるメンバを動的に追加・削除できるようなイメージがあるけど．
マルチキャストデリゲートは機能の追加・削除が行えるけど名前に関しては静的だよね．
03581
NGNGpublic delegate void PrintDelegate();
public PrintDelegate Print;
}
Hoge hoge = new Hoge();
hoge.Print += new PrintDelegate(_PrintHello);
hoge.Print += new PrintDelegate(_PrintBye);
hoge.Print();
スロットだとこんな感じ？
class Hoge {
}
hoge.PrintHello = _PrintHello;
hoge.PrintBye = _PrintBye;
hoge.PrintHello();
hoge.PrintBye();
0359デフォルトの名無しさん
NGNGんで slot の場合には、例えば
if a.hasSlot('asText') then
write( a.asText() );
else
write( "unknown object" );
みたいに、「無い」ということも積極的に使うスタイルになります。
DOM の attribute と似てる。
0360デフォルトの名無しさん
NGNG結局のところ現状のプロトタイプベースより現状のクラスベースのほうが使いやすいのかも。
(一般的なプログラマにとっては)
一部の神にとっては全てを思い通りに動的にできるプロトタイプベースのほうがいいのかもしれんが。
0361デフォルトの名無しさん
NGNG> 多分このスレに書き込んでいるほとんどの人はプロトタイプベースOOPL
> を使った開発なんてまともにやったことないでしょう．(私も含めて)
プロトタイプベースは言語よりもむしろ環境として生きるものだと思うなあ。
スクリプトもいいけど、やっぱオブジェクトを記述するメディアとしては
テキストというのは不適合っつーかさ。
>>342
Smalltalk系で言えば、PARTSとかVisualSmalltalkとかあったなあ。
これはクラスベースの環境の上にプロトタイプベース環境を構築したものだから、
ハイブリッドだな。
0362デフォルトの名無しさん
NGNG> 結局のところ現状のプロトタイプベースより現状のクラスベースのほうが使いやすいのかも。
むしろ、現状を肯定する材料を無意識に探している人も多いんじゃないかと思われ。
クラスベースのほうがいいという理由として最適化を出した人がいるけど、
それで何パーセントパフォーマンスが上がるのか。その何パーセントかが
クリティカルになるシステムが一体どれだけあるのか。
クラスで整理したほうがいいと言いながら、
後になってから1つのクラスを2つのサブクラスに分割する時の手間は
「仕方ない」で済ませてしまう。動的型付ならともかく、静的型付で新しい
サブクラスに応じて型体系をきちんと見直して、インターフェイス型の
定義を洗い直して変数やメソッドの型を適切に修正したりするのは結構
無視できない量の作業のはずなのに。
そういったことを「言語のために負っている手間」と認識せずに
「本質的に仕方ないこと」と看倣している限りは、周りが皆動いてからで
ないと動かないんだろうな。
0363デフォルトの名無しさん
NGNGそういったクラスによるデメリットも、プロトタイプベースの動的さ故に生まれるカオスよりは
マシだということなのかもしれない。
普通のプログラマには枠が有ったほうがいいのかも。あまりに動的だと乗りこなせない。
世の中、Smalltalk, C++, Java とクラスベースで来てるから、
単に流れでクラスベースなだけかもしれないけど。
Kay, Stroustrup, Gosling は何故クラスベースを選択したんだろう。好み?
0364デフォルトの名無しさん
NGNG動的だろうが静的だろうが、クラスだろうがプロトタイプだろうが関係ないような。
0365デフォルトの名無しさん
NGNG> Kay, Stroustrup, Gosling は何故クラスベースを選択したんだろう。好み?
他の2人はともかく、Alan KayはSqueakのMorphでインスタンスベース風な
環境に取り組んでいるのですが・・・
0366デフォルトの名無しさん
NGNG・クラスベースの方が数倍は速い．(実行速度のことね)
・型付けされていればバグが減る．
ちなみに俺はクラスベースの方がいいとは思ってないが，
クラスベース<プロトタイプベースとも思ってない．
0367デフォルトの名無しさん
NGNG> ・クラスベースの方が数倍は速い．(実行速度のことね)
これは具体的に何と何の比較？SelfとSmalltalkでこの差が出る？
それともSelfとC++？
どっちかっつーと、クラスベース/プロトタイプベースの比較以上に
プリミティブ型や演算子などの扱いとかのほうが
直接パフォーマンスに効いてくるんじゃないかと思うが。
あと、VMかネイティブコンパイラかのほうが大きいかもしれない。
> ・型付けされていればバグが減る．
プロトタイプベースでも静的型付は可能でしょ。
ただ単に、プロトタイプベースの良さを引き出すためには
多くの言語が動的型付を採用しているというだけの話で。
実際、スロットの動的追加はsubtypingとして元の型のままと看倣せるし、
スロットの変更についても、代入と同様の型チェックを実行するだけの話では？
スロットの削除はコピー生成時からあるスロットに対してのみ削除を禁止して、
動的に追加されたスロットは削除してもいいと思うし。
0368367
NGNG(1) 既存のオブジェクト指向プログラミング言語/環境の比較として、
クラスベースとプロトタイプベースのものに分けて比較する。
(2) オブジェクト指向プログラミング言語/環境を設計するための
技術要素としてのクラスベース/プロトタイプベースの利点/欠点を
比較する。
のうち、どっちなんだろ。
最初のころは「プロトタイプベース・スクリプト言語へのクラス導入ハンターイ」
という意見があったんで(2)もアリだと思っていたのだが、
もし(1)のみが焦点ならば、>>367はとんでもなく的外れになるわけだが。
0369デフォルトの名無しさん
NGNG>実際、スロットの動的追加はsubtypingとして元の型のままと看倣せるし、
動的に追加したら、結局、動的に束縛しなきゃならないわけで、
静的型チェックによる速度向上なんか望めないような。。。
0370デフォルトの名無しさん
NGNG>オブジェクトを複製または継承によって生成を行う言語，
>プロトタイプベース・オブジェクト指向言語について語りましょうよ．
という趣旨で参加してますた。
だからクラス付き言語との比較の話は「スレ違いだけど、まぁ仕方ないか」って感じで。
0371デフォルトの名無しさん
NGNGものとは無関係だと思うね。
「オブジェクト指向」を純化させると「プロトタイプベース」になる
というのは理解できるけれども、クラスという仕組みはやはり便利だし、
「プロトタイプベース」であることの利点を述べているつもりでも、
実はその言語が「動的変更をどれだけ許すか？」を語っているだけ
じゃないかと思うことが良くある。
そして「動的vs静的」は古来「柔軟性vs効率」の戦いになって不毛。
0372デフォルトの名無しさん
NGNGttp://member.nifty.ne.jp/masarl/article/js-oop.html
ttp://www.tokumaru.org/JavaScript/
以外で。
JavaScriptなのは他にプロトタイプベース言語知らないから。
ドキュメント豊富なのってこいつくらいだよね。SelfだのNewtonScriptだのは全然見かけないし
0374デフォルトの名無しさん
NGNGクラスベースでも動的変更は出来るから，
「クラスベース: 静的」「プロトタイプベース: 動的」とは言えない．
プロトタイプベースとクラスベースの本質的違いはそこではない．
0375デフォルトの名無しさん
NGNG説明してくれると嬉しいんだが。RAD だのオブジェクトを触って変更できるって
動的言語なら大抵そうじゃない？オブジェクトを触るっていうけど、別にｸﾗｽﾍﾞｰｽ
だって動的言語なら大抵オブジェクトを操作できますよね？一オブジェクトだけ
メソッド追加/変更とか。
理論的にシンプル（概念が少ないから）だから…というくらいしかわかんないなぁ。
で、とりあえずやってみりゃ分かるだろと思って Self ってのを試そうと
思ったんだが x86 じゃ動かないみたいだし。結局 2ch で聞いてしまうわけだ…。
0376デフォルトの名無しさん
NGNGSmalltalk以外には何があるの?
0377デフォルトの名無しさん
NGNG違いとかじゃなくてクラスベースだとﾏｽﾞｰだけどプロトタイプだとｳﾏｰな点を指摘して
やればいいだけんじゃないのかと思われ。
0378デフォルトの名無しさん
NGNGクラス自体を新しく作って、オブジェクトのクラスを変更するんならともかく。
漏れ的にはプロトタイプベースの言語でも大抵なんでもできるんじゃないの、って立場なんで、
逆に 375 の人に「なんでクラス付き言語の方がいいの？」ってのを具体的に聞いてみたい。
広く使われていてライブラリが充実しているので Java がいい、とか、実行速度が速くて
ジェネリックスがやりやすいので C++ がいい、とかさ。
0379デフォルトの名無しさん
NGNGプロトタイプベース言語はクラスベース言語の何かについての反省から生まれてきたわけではないし、
誰も「喪前らクラスベース言語はマズイですよ」とも言ってないわけだから、
「クラスベースだとマズー」→「プロトタイプベース言語でウマー」ってのが無きゃならない・あるはずだ、
ということはないと思うんだけど。
0380デフォルトの名無しさん
NGNG> だって動的言語なら大抵オブジェクトを操作できますよね？一オブジェクトだけ
> メソッド追加/変更とか。
クラスベースできるけどその言語本来が狙っているやり方じゃないような。
純粋にクラスベースで1つのオブジェクトだけメソッドやイ変数を追加しようとしたら、
そのために動的にクラスを生成してそのクラスのインスタンスに化けるという操作
が必要になる。
じゃあその動的に生成したクラスの名前はどうするってこととか、どっかシステム中
に元のクラスを参照している部分があったらそこも変更しなきゃいけないのかとか、
結構面倒なことになる。
で、例えばクラス名は適当に番号か何かを付けて自動的に名前を生成しても、
そんな適当な名前がクラスライブラリに混入することはクラスベースで想定していた
「良いプログラミング」とはかけ離れたものになるんじゃないかな？
そういうクラス絡みの「やり難さ」を取り除くには、クラスでの定義とは独立して
メソッドや変数を追加できる機構が必要になると思われ。
俺的には、そういう機構さえあれば、別にクラスが存在していてもいいと思ってる。
0381デフォルトの名無しさん
NGNGてっきり、クラスベースのなにかを反省して出来たのかと思ったけど、
そうじゃないわけね。うーむ、とりあえず試してみたいがなんか x86 で
動くやつのオススメをキボンヌ。
> １オブジェクトだけメソッド追加/変更なんて出来るクラスベース言語ってあるのかな
例えば CLOS ではできたYO。基本はクラス単位だけどオブジェクト単位でも定義できる。
ついでにメソッドコンビネーションで特定のメソッドの前後に処理を追加するとかもできるのが面白い
と思った。つまり特定のオブジェクトのあるメソッドの前にだけ処理を挿入とかできるｳﾏｰ。
ｳﾏｰな例：
このｵﾌﾞｼﾞｪｸﾄはﾕｰｻﾞｰが触ったやつだから消えるときは知らせよう→削除しますた表示をｵﾌﾞｼﾞｪｸﾄに追加
0382デフォルトの名無しさん
NGNG漏れのような現場の土方には思考の訓練の道具ってだけだな
0383デフォルトの名無しさん
NGNG> 動的に追加したら、結局、動的に束縛しなきゃならないわけで、
> 静的型チェックによる速度向上なんか望めないような。。。
いや、他のオブジェクトのメソッドからは、追加したメソッドは叩けないだろ。
静的型チェックしているから。
動的に追加したスロットは、一緒に動的に上書き変更したメソッドの中からしか
叩けないんじゃないかな。
で、それらのスロットを取り除く時には動的チェックするか、あるいは
一緒に動的に追加したスロット群全部をいっぺんに取り除くことにする
って感じでどうよ？
かなり窮屈なプロトタイプベースだが(苦
0384381
NGNG>そのために動的にクラスを生成してそのクラスのインスタンスに化けるという操作
>が必要になる。
そんなことは無かったと思うけど…。
(defmethod hoge ((self クラス名)) ....)
(defmethod hoge ((self (eql オブジェクト))) ...)
こんだけなんで、単にメソッド検索時にオブジェクト＞クラスな
優先順位になってただけじゃないかなと思われ。
でもクラスがどうのとかはいいからプロトタイプベースの処理系を
オススメしてくれょぅ。触ってみたいんだよぅ。Self が動かなくて
悔しいんだよぅ。x86 で動かせるやつ。OS は Win か Linux か *BSD くらいで。
0385デフォルトの名無しさん
NGNG0386デフォルトの名無しさん
NGNGプロトタイプベース言語は、オブジェクト指向言語の一派というよりも、
ミンスキーのフレーム理論の直接の形式化で、
「オブジェクト」ではなく「フレーム」を基本的なデータ構造としています。
ttp://www.symlab.sys.i.kyoto-u.ac.jp/lecture/ai/ai.PDF
のp38あたりからを参照。
0387デフォルトの名無しさん
NGNG一応年のため聞くけど、処理系は IE とか Mozilla でいいんですよね？
0388デフォルトの名無しさん
NGNG上の方にリンクが載っているが、Io とか Cecil なら x86 でも動くはず。
Win で Cecil 動かしてる人がいるから参考まで。
ttp://www.kmonos.net/alang/etc/cecil.php
0389デフォルトの名無しさん
NGNG0390デフォルトの名無しさん
NGNG淡々と説いているが…？ ただ、結果としてはこのスタンスがまずかった。
オブジェクトベース（aka プロトタイプベース）がまるでクラスベースの対局だという
ような考え方を一般に植え付けてしまったから。
プロトタイプベースって言葉が悪いんだよね。おそらくここで意見を交わし合うべきは
オブジェクトベース（あるいはクラスを意識するならインスタンスベース）のオブジェクト vs
クラスベースのオブジェクトなのであろうかと思うのですが、いかがでしょうか？＞1さん
つまり、オブジェクトが自由に値スロットやメソッドスロットを追加できるとき、どんな
メリット（やデメリット）があるのかとか、スロットへのアクセスにはどんな方法がベターか
とか、そんな話で盛り上がった方がおもしろいと、まあ、そんなふうに思うわけです。
プロトタイプベースとくくってしまうと、オブジェクトの移譲先としてプロトタイプが良いか、
クラスが良いかという結局、好みの問題に終始してしまうので不毛かなと。
03911
NGNGここにあるSelfのcygwin版，動かないんだよねぇ…
http://www.gliebe.de/self/index.html
とりあえず，Cecilなんてどうでしょうか？
http://www.cs.washington.edu/research/projects/cecil/www/Release/
Interpreterをダウンロードして展開すればすぐに遊べますよ．
ここでも見ながら→http://www.kmonos.net/alang/etc/cecil.php
俺はまだほとんど使ってないけど…コレはかなり楽しそう．
03921
NGNGつかレス速っw
>>390
>プロトタイプベースって言葉が悪いんだよね。おそらくここで意見を交わし合うべきは
>オブジェクトベース（あるいはクラスを意識するならインスタンスベース）のオブジェクト vs
>クラスベースのオブジェクトなのであろうかと思うのですが、いかがでしょうか？＞1さん
激しく同意です．
ただ私は無知なのでなかなか積極的に話題振ったりできませんが…
0393デフォルトの名無しさん
NGNGしてるとは思えないなぁ．
クラスがない方が自然なの気がするけど，それ以上にプロトタイプのチェインは
不自然な概念だと思う．
0394デフォルトの名無しさん
NGNG>>389 ちょっと前でも JavaScript って話だったじゃないか……正直 age に騙された。
お前らいい香具師らじゃないか。遊んでみるYO!!
で、>>386 のを脳内解釈したところ、
×クラスベースがあってそれをほにゃほにゃしてプロトタイプベースができた
○プロトタイプベースを実現した。で、クラスと比較して～
という理解でいいのかな。
0395デフォルトの名無しさん
NGNGでもそれでは，1つ1つのオブジェクトが同じメソッドをバラバラに持ってるのは
効率が悪いから，プロトタイプやらクラスやらが導入されたんじゃないの?
0396デフォルトの名無しさん
NGNGやっぱ焦点はオブジェクト単位のスロット管理のpros/consだわな。
つまり>>384さんの流れで言うと、CLOSもインスタンスベースとしての機能「も」
持っているわけで。
0397デフォルトの名無しさん
NGNG何度か出ているけど、CLOS をクラスベースの引き合いに出すのは混乱するから
やめたほうがよいと思いますよ。CLOS のオブジェクトは、スロットこそクラスベース
のオブジェクトと同様にクラスを鋳型にしていますが、メソッドのほうは総称関数という
まったく別の機構で扱われているわけで、誤解を恐れずいうなら、これは抽象データ型
だとかオブジェクト指向とかいった次元を超越した機構なわけですから。
0398380
NGNGまぎらわしい書き方してすまんです。>>380での「純粋にクラスベースで」とは、
「クラスが管理しているスロット定義情報のみで」という意味のつもりでした。
ので、>>834で挙げてもらったCLOSでの例は「純粋にクラスベースで」には
含めないつもりでした。
で、>>381に挙げてもらった例には大枠で賛成です。
特に、言語レベルでbeforeやafterが使えるのはイイねえ。
0399380
NGNG> つまり、オブジェクトが自由に値スロットやメソッドスロットを追加できるとき、どんな
> メリット（やデメリット）があるのかとか、スロットへのアクセスにはどんな方法がベターか
> とか、そんな話で盛り上がった方がおもしろいと、まあ、そんなふうに思うわけです。
もうちょい厳密に言うと、それを言語仕様または処理系レベルでサポートすることの
メリット/デメリットということで、どうでしょうか？
そういうオブジェクトを構築できるかどうかということになると、
クロージャを扱える言語/処理系ならば、そういうクラス/オブジェクトを
ユーザの手で作ることができるわけで、それではむしろデザインパターンと
変わらなくなるような気がするので。
0400380
NGNG> メソッドのほうは総称関数という
> まったく別の機構で扱われているわけで、誤解を恐れずいうなら、これは抽象データ型
> だとかオブジェクト指向とかいった次元を超越した機構なわけですから。
でもマルチメソッド萌え・・・スレ違いスマソ。
0401デフォルトの名無しさん
NGNGまあ、それは言わずもがなでしょう。オブジェクト指向におけるオブジェクトの
オールマイティ性（と、同時にそれが苦手とすること）ってのは Smalltalk システムが
早々と明らかにしてしまっていますから、ことさらにここでそれを強調する必要もなかろうかと。
そんなことを言い出したら、Lisp 屋さんが出てきて、そんなのオブジェクトなんか使わんでも
俺たちならもっと巧くやれる！ってなことになりかねない(笑)。
0402デフォルトの名無しさん
NGNGスレの流れ的には大賛成だが、
>クロージャを扱える言語/処理系ならば、そういうクラス/オブジェクトを
>ユーザの手で作ることができるわけで、
こっちの方が超ステキ！（ｷﾗﾝ
0403デフォルトの名無しさん
NGNGSmalltalkでプロトタイプベースとは、おめでてぇや。
Selfが動くVMイメージ持ってるの？
0404デフォルトの名無しさん
NGNG禿同
0405デフォルトの名無しさん
NGNG0406デフォルトの名無しさん
NGNG､ミ川川川彡 ,ｨｒ彡'";;;;;;;;;;;;;;;
ミ 彡 ,.ｨi彡',.=从i､;;;;;;;;;;;;
三 ギ そ 三 ,ｨ/ｲ,r'" .i!ｌi,il i､ﾐ',:;;;;
三. ャ れ 三 ,. -‐==- ､, /!li/'/ l'' l', ',ヾ,ヽ;
三 グ は 三 ,,__-＝ﾆ三三ﾆヾヽl!/,_ ,_i ､,,.ｨ'=-､_ヾヾ
三 で 三,. ‐ﾆ三＝,=＝‐ ''' `‐゛j,ｪﾂ''''ｰ=5ｒ‐ｫ､, ヽ
三. 言 ひ 三 .,,__／ . ,' ﾝ′ ￣
三 っ ょ 三 / ｉ l,
三. て っ 三 ﾉ ..::.:... ,_ i ! `´' J
三 る と 三 iｪｧﾒ`'7rｪ､,ｰ' i }ｴ=､
三 の し 三 ﾉ "' ￣ ! '';;;;;;;
三 か て 三. ｉヽ,_ﾝ J l
三 !? 三 !し=､ ヽ i ,.
彡 ミ ! "'' `'′ ヽ、,,__,,..,_ｨ,..ｒ,',",
彡川川川ミ. l _, , | ` ｰ､≡＝,ﾝ _,,,
ヽ、 _,,,,,ィﾆ三"'" ,,.'ヘ rｰ‐ ''''''"
`, i'''ﾆ'" ,. -‐'" `/
ヽ ! i´ ／
ノレ'ー'! ／ O
0407デフォルトの名無しさん
NGNG辞書でも用意して、名前と値をぽんぽん追加してくだけでいいんかな。
0409デフォルトの名無しさん
NGNG突っ込むだけでしょ？で、オブジェクト複製用のオペレータがあれば
一応プロトタイプベースﾃﾞｷﾀ！くらいならスクリプト系言語なら簡単に
できません？他にも何かいるのかな？
0410デフォルトの名無しさん
NGNG委譲機構
0411デフォルトの名無しさん
NGNG見つからなかったらそっちから順番に検索…とかじゃ駄目っすかね？
0412n
NGNGattr_accessor :slot,:proto,:mixin
def initialize; @slot = Hash.new; @proto = nil; @mixin = Array.new; end
def inherit; obj = Proto.new; obj.proto = self; return obj; end
def call(key); if @slot.key?(key) then @slot[key].call else self.proto.call(key) end;end
def set(key,val); @slot[key]=val; end
def get(key)@slot[key]end
end
foo = Proto.new
foo.set "foo",proc{puts"foo"}
foo.set "hello",proc{puts"Hello,Foo!"}
bar = foo.inherit
bar.set "bar",proc{puts"foo"}
bar.call("foo")
bar.call("hello")
hoge = bar.inherit
hoge.set "hello",proc{puts"Hello,Hoge!"}
fuga = hoge.inherit
fuga.call("foo")
fuga.call("hello")
foo.call("hello")
こんな感じですか？
0413デフォルトの名無しさん
NGNG0414デフォルトの名無しさん
NGNG聞いたこともない言語ばかりだなぁ
0415デフォルトの名無しさん
NGNGたとえば、call でそのメソッドを起動したとき、レシーバの get "foo" が "foo" なら "yes"、
そうでなければ "no" と答える "is_foo?" というメソッドスロットを foo に追加できますか？
0416デフォルトの名無しさん
NGNGpython みたいに proc の引数に明示的に self 相当のものが。
0418デフォルトの名無しさん
NGNGSqueak上で動くSelfとか、Smalltalk無しで動くSelfとか、
Sunの研究部門が数年前に出してたっけ？もしかして。
0419デフォルトの名無しさん
NGNG10年近く前に探しに行った時は、
・Smalltalk VMが必要なﾊﾞｰｼﾞｮﾝとか、
・Sparc上で動くバイナリしかなくて、
ﾀﾞｳﾝﾛｰﾄﾞしても実行に困った覚えがあったっけ。
今はＭａｃ上に移植されてるのか。おまぃら、いい時代に生きてますね
http://research.sun.com/research/self/
--------------------------------------------------------------------------------
Self 4.2
Self 4.2 is the most recent public release (June 2003). It features the optimizing compiler on the PowerPC. Jump here to find out more.
--------------------------------------------------------------------------------
Self 4.1
Self 4.1.6 was the most previous public release (September 2002). It runs on the Macintosh as well as on machines from Sun Microsystems, Inc. Jump here to find out more.
--------------------------------------------------------------------------------
Self 4.0
Self 4.0 was a previous public release (July 1995). Jump here to find out more.
0420デフォルトの名無しさん
NGNGclassといってもオブジェクト生成関数みたいなもんだよね?
0421デフォルトの名無しさん
NGNGYes.
> classといってもオブジェクト生成関数みたいなもんだよね?
Yes.
ところでPythonはインスタンス固有のメソッド(Rubyでいう特異メソッド)
を作れるのに、多分誰も利用してませんね・・・。
0423n
NGNGclass Proto
attr_accessor :slot,:proto
def initialize; @slot = Hash.new; @proto = nil end
def inherit; obj = Proto.new; obj.proto = self; return obj end
def call(key,*arg)
if @slot.key?(key) then
return @slot[key].call(self,*arg)
else
obj = self
while obj = obj.proto; if obj.slot.key?(key) then return obj.slot[key].call(self,*arg) end end
end
end
def set(key,val); @slot[key]=val; end
def get(key)@slot[key]end
end
foo = Proto.new
foo.set "foo","foo"
foo.set "is_foo?",lambda{|this|this.get("foo") == "foo" ? "yes" : "no"}
puts foo.call("is_foo?") #=>"yes"
bar = foo.inherit
bar.set "foo","bar"
puts bar.call("is_foo?") #=>"no"
ちょっと強引ですが、こうすればレシーバのメソッドも呼べます。
0424デフォルトの名無しさん
NGNG乙。bank_account を組んでみました。
bank_account = Proto.new
bank_account.set "get_balance", proc{|this| this.get "balance"}
bank_account.set "set_balance", proc{|this, x| this.set "balance", x}
bank_account.call "set_balance", 200
bank_account.set "deposit", proc{|this, x| this.call "set_balance", (this.call "get_balance") + x}
bank_account.call "deposit", 50 => 250
bank_account.set "withdraw",
proc{|this, x| this.call "set_balance", [0, (this.call "get_balance") - x].max}
bank_account.call "withdraw", 100 => 150
bank_account.call "withdraw", 200 => 0
my_account = bank_account.inherit
my_account.call "set_balance", 100 => 100
my_account.call "deposit", 50 => 150
my_account.call "withdraw", 100 => 50
0425デフォルトの名無しさん
NGNG続き、
stock_account = bank_account.inherit
stock_account.set "get_num_shares", proc{|this| this.get "num_shares"}
stock_account.set "set_num_shares", proc{|this, x| this.set "num_shares", x}
stock_account.call "set_num_shares", 10
stock_account.set "get_price_per_share", proc{|this| this.get "price_per_share"}
stock_account.set "set_price_per_share", proc{|this, x| this.set "price_per_share", x}
stock_account.call "set_price_per_share", 30
stock_account.set "get_balance",
proc{|this| (this.call "get_num_shares") * (this.call "get_price_per_share")}
stock_account.call "get_balance" => 300
stock_account.set "set_balance",
proc{|this, x|
this.call "set_num_shares", Float(x) / (this.call "get_price_per_share")
this.call "get_balance"}
stock_account.call "deposit", 60
stock_account.call "get_num_shares" => 12.0
0426デフォルトの名無しさん
NGNGどうやって作るの？データは簡単に作れるけどメソッドの追加ができん……
0427デフォルトの名無しさん
NGNGRubyとかいう出来損ないの言語とちがって。
0428デフォルトの名無しさん
NGNG0429デフォルトの名無しさん
NGNGまずオブジェクト指向。もうただのオブジェクト指向なんてもんじゃない。純粋オブジェク指向。
オブジェクト指向といとかっても「基本型は別なんでしょ？」とか、もう、そういうレベルじゃない。
何しろ全部オブジェクト。スゲェ！なんか特別扱いとか無いの。数値も文字列も全部オブジェクト。
<!-- しかも他の言語をリスペクトしてるらしい。ヤバイよ、（パク）リスペクトだよ。
だって普通は他の言語をリスペクトしといて機能取り込んだ後叩くとかしないじゃん。
だってリスペクトしたって事はどっちかっつーと恩があるわけじゃん。
リクペクトしといてあとてやーいやーいザマーみろとか言わないっしょ。だから普通はリスペクト元の言語貶したりしない。話のわかるヤツだ。
けど Ruby はヤバイ。そんなの気にしない。貶しまくり。
他言語から心底ウザがられても「悔しがってる」「負けおしみですか？」とかよくわかんないくらい信者強気。ヤバすぎ。 -->
オブジェクト指向っていったけど、もしかしたらオブジェクト指向が最後のパラダイムかもしんない。でも最後って事にすると
「じゃあ、Ruby 最強？」
って事に<!-- 信者の脳内では-->なるし、それは誰も止められない。ヤバイ。誰にも止められないなんて凄すぎる。
あと超ユーザビリティ高い。end で終るから。shift 押さなくて良いんだって。ヤバイ。凄すぎ。括弧は最悪インデントは基地外。怖い。
それに超拡張モジュール書きやすい。GC のおかげらしい。参照カウントとかすると拡張モジュール内でその辺気にしなきゃいけないじゃん？でも Ruby は平気。C スタックとか平気でスキャンしてくれる。C スタックて。小学生でも直接操作しねぇよ、最近。
でも Ruby は全然平気。 C を C のまま扱ってる。凄い。ヤバイ。
とにかく貴様ら、Ruby のヤバさをもっと知るべきだと思います。
そんなヤバイ Ruby で作られたアプリケーションとか超偉い。もっとがんばれ。超がんばれ。
0430デフォルトの名無しさん
NGNG0431デフォルトの名無しさん
NGNG確かにうんこの味がしました。
Rubyはうんこです。
間違いありません。
Rubyなんて大層な名前はやめて、○んこと改名すべきです。
0432デフォルトの名無しさん
NGNG0433デフォルトの名無しさん
NGNG421-422 じゃないけど、Python 学習をかねて調べてみました。
class Foo:
def f(self): return "I'm of class"
foo = Foo()
foo.f() => "I'm of class"
bar = Foo()
bar.f() => "I'm of class"
def newF(): return "I'm *not" of class"
foo.f = newF
foo.f() => "I'm *not* of class"
bar.f() => "I'm of class"
def anotherF(self): return "I'm *also* of class"
Foo.f = antoherF
foo.f() => "I'm *not* of class"
bar.f() => "I'm *also* of class"
0434426
NGNGそれではただ関数を入れてるだけではないか。
漏れの求めるメソッドは↓で言うところの呼び出し時の冗長な obj を省ける
いわゆるメソッドが追加できるのか調べているのだが…。
class Object:
pass
obj = Object();
def say(self, msg):
print msg
obj.say = say
print obj.say
obj.say(obj, "hello") # obj ウザー
obj.say(obj, "humm") # ウザー
0435デフォルトの名無しさん
NGNGnewモジュールを使うナリよ。
0436デフォルトの名無しさん
NGNGｽﾏｿ低能なのでﾏﾆｭｱﾙ見たんだが良くわらん．ｻﾝﾌﾟﾙｷﾎﾞﾝﾇ
0437デフォルトの名無しさん
NGNG0438デフォルトの名無しさん
NGNGそうなりか！ さんくす
Python 学習を兼ねて、調べて書いてみました。
import new
class Obj:
def m(self): print "method of " + self.__class__.__name__
obj1 = Obj()
obj1.m() => 'method of Obj'
obj2 = Obj()
obj2.m() => 'method of Obj'
def m(self): print "method *not* of " + self.__class__.__name__
obj2.m = new.instancemethod(m, obj2, Obj)
obj2.m() => 'method *not* of Obj'
obj1.m() => 'method of Obj'
obj3 = Obj()
obj3.m() => 'method of Obj'
0439デフォルトの名無しさん
NGNGPython固有の問題なのかどっち?
0440デフォルトの名無しさん
NGNGクラスベースだからでもあり、Pythonだからでもあり。
本格的に使用するもんじゃないと思われ。
0441デフォルトの名無しさん
NGNGちょっと残念．
0442デフォルトの名無しさん
NGNG参考までにほぼ同様のことを Ruby と CLOS で、
class Obj
def m; p "method of " + self.class.name; end
end
obj1 = Obj.new
obj1.m => "method of Obj"
obj2 = Obj.new
obj2.m => "method of Obj"
def obj2.m; p "method *not* of " + self.class.name; end
obj2.m => "method *not* of Obj"
obj1.m => "method of Obj"
obj3 = Obj.new
obj3.m => "method of Obj"
0443デフォルトの名無しさん
NGNG(defmethod m ((self <obj>))
(concatenate 'string
"method for an ordinary " (string (class-name (class-of self))))))
(setq obj1 (make-instance '<obj>))
(m obj1) => "method for an ordinary <OBJ>"
(setq obj2 (make-instance '<obj>))
(defmethod m ((self (eql obj2)))
(concatenate 'string
"method *not* for an ordinary " (string (class-name (class-of self))))))
(m obj2) => "method *not* for an ordinary <OBJ>"
(m obj1) => "method for an ordinary <OBJ>"
(setq obj3 (make-instance '<obj>))
(m obj3) => "method for an ordinary <OBJ>"
0444デフォルトの名無しさん
NGNGObject
subclass: #Obj instanceVariableNames: '' classVariableNames: ''
poolDictionaries: '' category: 'Category-Name'.
Obj compile: 'm ↑''method of '', self class name' classified: nil.
obj1 ← Obj new.
obj1 m => 'method of Obj'
obj2 ← Obj new.
obj2 m => 'method of Obj'
obj2 assureUniClass.
obj2 class compile: 'm ↑''method *not* of '', self class name' classified: nil.
obj2 m => 'method *not* of Obj1'
obj1 m => 'method of Obj'
obj3 ← Obj new.
obj3 m => 'method of Obj'
ただし、この時点で、
obj1 class == obj2 class. => false
obj2 class superclass == obj1 class => true
obj1 class == obj3 class. => true
0445デフォルトの名無しさん
NGNGglobals _AddSlots: (| obj. obj1. obj2. obj3 |)
obj: (|
name <- 'obj'.
m = (^ 'method of ', parent name) |)
obj1: (| parent* = obj |).
obj1 m => 'method of obj'
obj2: (| parent* = obj |).
obj2 m => 'method of obj'
obj2 _AddSlots: (| m = (^ 'method *not* of ', parent name) |).
obj2 m => 'method *not* of obj'
obj3: (| parent* = obj |).
obj3 m => 'method of obj'
ただしここで obj は、クラス(or トレイト)っぽい位置づけ。
0446デフォルトの名無しさん
NGNGそれに近いのかな…。つまり、CLOS 、Python はインスタンスと
そのクラスとの関係には手を付けずに、注目するインスタンス専用の
メソッドを用意する。これに対して、Ruby (と、まあ Smalltalk/
Squeak)では元のクラスのサブクラスを作って、注目するインスタンス
のクラスをそれに差し替え、インスタンス特異的なメソッドは差し替え
たサブクラスに定義している。
ちなみに Ruby は構文の工夫や、無名クラスを明示的にしないことで、
さもインスタンスにそれ特異的なメソッドを追加できているように
見せかけているので、ユーザーには
0447デフォルトの名無しさん
NGNGどうも concatenate とか本質的でないとこで長くなってる気がするので CLOS 版は
format つかって文字列返すくらいにしといたほうがいいのでは？
(defclass <obj> () ())
(defmethod m ((self <obj>))
(format nil "method for an ordinary ~A~%" (class-name (class-of self))))
(setq obj1 (make-instance '<obj>))
(m obj1) => "method for an ordinary <obj>"
(setq obj2 (make-instance '<obj>))
(defmethod m ((self (eql obj2)))
(format nil "method *not* for an ordinary ~A" (class-name (class-of self))))
(m obj1) => "method *not* for an ordinary <obj>"
かつて Lisp 方面で CLOS ﾀﾞﾒﾎﾟプロトタイプベースｲｲ! って言ってた連中って
GUI ならプロトタイプのほうが自然だ ! とかプロトタイプベースのほうが速い! とか言っ
てたような記憶があるのです．やっぱ速いんですかね？
0448デフォルトの名無しさん
NGNG書きかけで送っちゃったけど、意味は通じるからいいかなと(笑)。
format はたしかにそうです。馴染みのないひとにも対応付け易い
よう、冗長にしてみました。ご指摘 & 実例たーしゃ。
ついでに Self も parent* スロットには暗示的にアクセスするので、
こちらも parent name などとする必要はなく、単に name だけに
すべきです。
0449デフォルトの名無しさん
NGNG> メソッドを用意する。これに対して、Ruby (と、まあ Smalltalk/
> Squeak)では元のクラスのサブクラスを作って、注目するインスタンス
> のクラスをそれに差し替え、インスタンス特異的なメソッドは差し替え
> たサブクラスに定義している。
>
12ﾍｪ～。純粋クラスベースOOの枠組み内でうまいことやってるですね。
ちなみにPythonが冗長なのは、滅多に使わないような機能や生産性にほとんど
影響しないようなところに安易に新しい構文を用意することで、言語が無駄に
複雑化したり初心者を混乱させたりするのは悪である、という思想があるから
のようです。ってプロトタイプとかけ離れてきたのでこの辺で。
0450デフォルトの名無しさん
NGNG> Experimental prototype base object orientation.
Scheme 処理系の一つ、QScheme はプロトタイプベースなオブジェクトシステムを
持ってるらしい。
0451デフォルトの名無しさん
NGNG言葉を見たよ（以前はそうでもなかったけど）。それともプロトタイプベースの認知度が
上がったのかな。
0452デフォルトの名無しさん
NGNG>Support for both class-based and prototype-based systems
>You may have, in the same application, class-based hierarchies (with instantiation
>and specialization relations) and prototype-based hierarchies (with extension relations).
Prolog のオブジェクト指向拡張ライブラリ? の Logtalk はクラスベースとプロトタイプ
ベースの両方をサポートしているみたい。Features 見ていると、色々面白そう。
0453デフォルトの名無しさん
NGNGIoですか？
0454デフォルトの名無しさん
NGNG0455デフォルトの名無しさん
NGNGMLud 自身も強く型付けされた環境なのかなぁ。だとしたらちょっと異色かも。
http://moonflare.com/code/mlud/index.php
0456デフォルトの名無しさん
NGNG言語に大きく依存した機能じゃないから、好きな言語でどうぞっていう流れじゃないかな。
クロージャがあるか、ファーストクラスのメソッドがあれば何とかなる。
0457デフォルトの名無しさん
NGNG一番進んでいるのはオブジェクトモデル、VMの性能、クラスライブラリ
の充実度のどれをとってもいまだにSelfだろ。ちょっと古いのと、対象
となるプラットフォームが異常に限られているのが玉に瑕だが。
NewtonScript もかなりよくできていたけど、これはプラットフォーム
自体がなくなっちゃったからなぁ…。
目先を変えて、Scheme の SLIB に含まれる YASOS なんかもいいかもしれない。
ttp://members.at.infoseek.co.jp/zzyyb/scm/slib-ja/slib_2.html#SEC35
0458デフォルトの名無しさん
NGNGインスタンス特異的メソッドのみならともかく、委譲機構をそれなりに
実現しようとすると結構な手間になるのでは？
0459デフォルトの名無しさん
NGNG委譲機構とやらのサンプルコードをキボンヌ。最低限どんな動きが
どれくれーできればいいんだ？
0460デフォルトの名無しさん
NGNG既出ですが、これなんかよく説明されていると思います。
ttp://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/seruby/
サンプルコードの書き下ろしは面倒なので勘弁してください。
私自身は、簡単にできるとは思っても言ってもいないので、説明責任もないし(^_^;)。
最低限できればよいのは、委譲先オブジェクトのメソッドを暗示的
(レシーバには見つけられないとき)に、あるいは必要なら明示的 (Self の
resend、Smalltalk 系の super）に起動できて、その際、起動した
メソッドのコード中の偽変数 self には(メソッドホルダではなく)
レシーバを束縛できていること、でしょうか。
0461デフォルトの名無しさん
NGNGつまり委譲機構ってのは手前で処理できぬメッセージが来たら
プロトタイプチェーンを遡ってメソッドを探す事っつーことですか。
クラスベースだと何に当たる言葉なんだろう。「ポリもアフィズム」じゃないし。
self / this にそもそもメッセージを受けた人が入らないといけないが、
クラスベースなら[[クラスの]]継承階層を遡っていき、クラスとオブジェクトが峻別されるから
あまり問題にならないところだが、
プロトタイプベースだと[[オブジェクトの]]チェーンを遡っていくんだが
でも親のオブジェクトが受けちゃったりしたらまずいって訳だ。
RubyもSelfもわからんので読めん。
漏れの読めるプロトタイプベースはECMAScriptだけでいいや・・・。
0462n
NGNGわたしにはろくに継承/委譲ができないように思えるのですが・・・。
0463デフォルトの名無しさん
NGNG勉強を兼ねて恒例の bank account を書いてみました。
委譲/継承も多態もできているみたいです。
個人的には self をメソッドで暗示的引数に指定しなくていいぶん、
Python よりはスジがよいように思います。
<script type="text/javascript">
var bank_account = new Object;
function ba_set_balance(_x) {this.balance = _x; return this}
bank_account.set_balance = ba_set_balance;
function ba_get_balance() {return this.balance}
bank_account.get_balance = ba_get_balance;
document.write( bank_account.set_balance(200).get_balance() + "<br>"); // => 200
function ba_deposit(_x) {
this.set_balance(this.get_balance() + _x);
return this}
bank_account.deposit = ba_deposit;
document.write( bank_account.deposit(50).get_balance() + "<br>"); // => 250
function ba_withdraw(_x) {
this.set_balance(Math.max(this.get_balance() - _x, 0));
return this}
bank_account.withdraw = ba_withdraw;
document.write( bank_account.withdraw(100).get_balance() + "<br>"); // => 150
document.write( bank_account.withdraw(200).get_balance() + "<br>"); // => 0
0464デフォルトの名無しさん
NGNGvar my_account = new Object;
my_account.__proto__ = bank_account;
document.write( my_account.set_balance(100).get_balance() + "<br>"); // => 100
document.write( my_account.deposit(50).get_balance() + "<br>"); // => 150
document.write( bank_account.get_balance() + "<br>"); // => 0
0465デフォルトの名無しさん
NGNGfunction sa_set_num_shares(_x) {this.num_shares = _x; return this}
stock_account.set_num_shares = sa_set_num_shares;
function sa_get_num_shares() {return this.num_shares}
stock_account.get_num_shares = sa_get_num_shares;
function sa_set_price_per_share(_x) {this.price_per_share = _x; return this}
stock_account.set_price_per_share = sa_set_price_per_share;
function sa_get_price_per_share() {return this.price_per_share}
stock_account.get_price_per_share = sa_get_price_per_share;
stock_account.set_num_shares(10).set_price_per_share(30);
document.write( stock_account.get_num_shares() + "<br>"); // => 10
document.write( stock_account.get_price_per_share() + "<br>"); // => 30
0466デフォルトの名無しさん
NGNGfunction sa_set_balance(_x) {
this.set_num_shares(_x / this.get_price_per_share());
return this}
stock_account.set_balance = sa_set_balance;
function sa_get_balance() {
return this.get_num_shares() * this.get_price_per_share()}
stock_account.get_balance = sa_get_balance;
document.write( stock_account.get_balance() + "<br>"); // => 300
document.write( stock_account.set_balance(600).get_balance() + "<br>"); // => 600
document.write( stock_account.set_balance(600).get_num_shares() + "<br>"); // => 20
document.write( stock_account.deposit(60).get_balance() + "<br>"); // => 660
document.write( stock_account.get_num_shares() + "<br>"); // => 22
document.write( stock_account.withdraw(90).get_balance() + "<br>"); // => 570
document.write( stock_account.get_num_shares() + "<br>"); // => 19
</script>
0467デフォルトの名無しさん
NGNG0468デフォルトの名無しさん
NGNGIEでは動かない。
セッターが必ずthisを返してメッセージをカスケードさせてるのは趣味?
Smalltalk以外でもそうするものなの?
Netscapeのガイド
ttp://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/obj2.html#1013803
だと、コンストラクタ作って、prototypeプロパティに継承元をセットしていて、クラスベースっぽい
0469デフォルトの名無しさん
NGNGvar stock_account = new Object;
stock_account.__proto__ = bank_account;
が抜けてる??
0470デフォルトの名無しさん
NGNGああ、すみません。抜けてます。465 と 464 の間に。
>>468
ああ、すみません。Smalltalker なもんですから…。
そうでないと気持ち悪くて…。
>>467
ああ、すみません。初めて書いた JavaScript なもんですから…。
でも、私の責任は１／３くらいです(^_^;)。
１／３は JavaScript のせい、１／３は２ちゃんの改行数制限せいです(笑)。
0471n
NGNG確かに__proto__が使えるならプロトタイプベースと呼べるとは思うのですが、
__proto__がなくてもプロトタイプベースなのかなぁ、と感じたのですよ。
0472デフォルトの名無しさん
NGNGもう少しJSらしく書いてみたけど、普通にやると多態は駄目。
var BankAccount = new Object;
BankAccount.balance = 200;
document.write(BankAccount.balance + "<br>"); // 200
BankAccount.deposit = function(x) { return this.balance += x; }
document.write(BankAccount.deposit(50) + "<br>"); // 250
BankAccount.withdraw = function(x) {
return this.balance = Math.max(this.balance - x, 0);
}
document.write(BankAccount.withdraw(100) + "<br>"); // 150
document.write(BankAccount.withdraw(200) + "<br>"); // 0
function make_Account(){}
make_Account.prototype = BankAccount;
var myAccount = new make_Account;
// Mozilla 系 JS ならば var myAccont.__proto__ = BankAccount だけでもいい。
myAccount.balance = 100;
document.write(myAccount.balance + "<br>"); // 100
document.write(myAccount.deposit(50) + "<br>"); // 150
document.write(BankAccount.balance + "<br>"); // 0
0473デフォルトの名無しさん
NGNGvar stockAccount = new make_Account;
// Mozilla 系 JS ならば var stockAccount.__proto__ = BankAccount でもいい。
stockAccount.numShares = 10;
stockAccount.pricePerShare = 30;
document.write(stockAccount.numShares + "<br>"); // 10
document.write(stockAccount.pricePerShare + "<br>"); // 30
stockAccount.balance = function(x) { // こんな風にしてみたけど…
if(arguments.length) this.numShares = x / this.pricePerShare;
return this.numShares * this.pricePerShare;
}
document.write(stockAccount.balance() + "<br>"); // 300
document.write(stockAccount.balance(600) + "<br>"); // 600
document.write(stockAccount.numShares + "<br>"); // 20
stockAccount.deposit(60);
document.write(stockAccount.balance() + "<br>");
// Error: stockAccount.balance is not a function
document.write(stockAccount.numShares + "<br>");
stockAccount.withdraw(90);
document.write(stockAccount.balance() + "<br>");
document.write(stockAccount.numShares + "<br>");
0474デフォルトの名無しさん
NGNGhttp://sumim.no-ip.com:8080/wiki/809 の Io の最初の例と同じで
# つか、上自体 Io の例そのままパクッただけだったり。
既にあるプロパティと同名のメソッドを作れない。
結局 getter, setter になるメソッドを書かないとうまくいかない。
0475デフォルトの名無しさん
NGNGの Chain of Responsibility を JS で。
var app = new Object;
app.preview = function(){alert("preview in app");}
function make_app(){}
make_app.prototype = app;
var dialog = new make_app;
dialog.print = function(){alert("print in dialog");}
function make_dialog(){}
make_dialog.prototype = dialog;
var button = new make_dialog;
button.help = function(){alert("help in button");}
button.help();
button.print();
button.preview()
すっきり書けてるほうとは思うけど、どうも…
0476デフォルトの名無しさん
NGNGvar app = new Object;
var dialog = new Object;
var button = new Object;
app.preview = function(){alert("preview in app");}
dialog.print = function(){alert("print in dialog");}
button.help = function(){alert("help in button");}
dialog.__proto__ = app;
button.__proto__ = dialog;
button.help();
button.print();
button.preview()
やっぱりこっちの方がプロトタイプっぽい。
0477デフォルトの名無しさん
NGNGapp.prototype.preview = function(){alert("preview in app");}
var dialog = new Function;
dialog.prototype = new app;
dialog.prototype.print = function(){alert("print in dialog");}
var button = new dialog;
button.help = function(){alert("help in button");}
クラスっぽく書くとこうか:p
0478デフォルトの名無しさん
NGNGfunction app(){
var name = "app";
this.preview = function(){alert("preview in" + name);};
}
function dialog(){
var name = "dialog";
app.apply(this, arguments);
this.print = function(){alert("print in" + name);};
}
var button = new dialog;
button.help = function(){alert("help in button");};
04791
NGNGapp = {
fun preview() {
do: println "preview in app";
};
};
dialog = app + {
fun print() {
do: println("print in dialog");
};
};
button = dialog + {
fun help() {
do: println("help in button");
};
};
button help ();
button print ();
button preview();
0480デフォルトの名無しさん
NGNG結局はこれ使って何するのか、だと思うよ。
これ使ったら開発効率が上がりました、
実行効率が上がりました、
保守がしやすくなりました、
ってスタンスのパラダイムじゃないよね。＞プロトタイプベース
趣味？
0481デフォルトの名無しさん
NGNGんー Newton Script なんかがまさにそうなんだけど、例えば HTML / XHTML のように
UI + action なんかをさらーっと記述するフレームワークなんかを考えると、ごく当たり前に
プロトタイプベースの発想になったりします。
<a id="a" onClick="hoge()"> a </a>
<a id="b" onClick="bar()"> b </a>
なんていうようなものを表現するとき、それぞれにクラスを作るのではなくインスタンス毎に
メソッドを定義して済ませてしまうとか。
0482デフォルトの名無しさん
NGNGすでにインスタンスベースの枠組み(UI + actionはその典型)があって、
それに乗っかる場合、っていう意味だろうか。
なんか受け身で消極的な感じがする。
0483デフォルトの名無しさん
NGNG0484デフォルトの名無しさん
NGNG乗っかるというか、全体を構築するために使ってもいいし (Newton は後者)。
ただ、フレームワークそのものはクラスベースでいいんじゃない、っていう見解は
ある意味当たり前にあって（フレームワークで定義されるものは普通汎用性を持っていて、
個別インスタンスなんて珍しいから）、そういう面では prototype 言語でも内部的に
クラスを使っていたりします。
↑漏れはNewtonScript と SpiderMonkey (Netscape 由来の JavaScript エンジン)位
しか詳しくないので信頼度低いけど。
0485デフォルトの名無しさん
NGNGC++でテンプレートによる「修飾」継承という手で爆発を抑えつつ多重分類を実現できそうな気が。
0486デフォルトの名無しさん
NGNG0487デフォルトの名無しさん
NGNG保守、ついでに戯言
Delphi の procedure | function 型のプロパティとか、
Java の匿名内部クラスとかでイベントを捕獲するのは、
メソッドをカスタマイズするという点でプロトタイプに通じる考えだと思う。
あると便利、なくてもほかに手段があれば別に困らないかもしれない。
0488デフォルトの名無しさん
NGNGどちらも、元のオブジェクトへの参照を保持しているだけですよね？
0489デフォルトの名無しさん
NGNGselfとsuperは同じオブジェクトを指す
0490デフォルトの名無しさん
NGNG言語によるかも。
0491デフォルトの名無しさん
NGNGSELF のリファレンスマニュアルのこれ、
http://research.sun.com/self/release_4.0/Self-4.0/Tutorial/Language/SyntaxAndSemantics/Resends.html
なんかみてみてもらうとわかると思うけど、それであながち間違いでもなさそう。
SELF の場合、self は self のままで（まぎらわしいなぁ…）、メソッドの呼び出し記述のほう
に resend を冠する。ただ、これはペアレント（aka proto）スロットが一つのときで、複数ある
ときはそれを明示的にするためにペアレントスロット名をもって resend に代える、とある。
まあ、SELF の話をされてもかなわんよ…という人も多いだろうから、なんか他の言語でも
調べてみることにするか。
0492デフォルトの名無しさん
NGNGttp://members.jcom.home.ne.jp/jintrick/Personal/d20043l.html#d20_1
0493デフォルトの名無しさん
NGNGプロトタイプベースとクラスベースの、どちらがより簡単で判り易い例えができるんでしょうね
クラスベースはクラス，つまり概念の継承なので、クラスに慣れるとクラスの例は
『クーラーボックスの親はただの箱』みたいでも違和感無いですが、
一般人には？？？な話でしょうし。（ちょっと説明すればわかると思いますが）
逆にプロトタイプの例では特定の個人を例に挙げなければ難しいですし。
（実際にプログラム内で操作するのは「個人」ですから、
実際の例を出せばこちらのほうが俺は判り易いと思いますが）
というかインスタンスとクラスの区別が厳密についてないですね俺 orz
クラスが無い分プロトタイプのほうが簡単ですか？
0494デフォルトの名無しさん
NGNGそこがもーダメなような
0495493
NGNG判ったつもりで判ってなかったんだな
0496デフォルトの名無しさん
NGNG0497デフォルトの名無しさん
NGNGんー。やっぱり プロトタイプベース vs クラスベース という構図が
そも間違っていると思う。プロトタイプベースはよりプリミティブな
オブジェクトモデルなんで、クラスベースがよい仕事をする問題領域なら
機能を制限してそうしたフレームワークを組めばいい（ひらたく言えば
クラスベースを使えばいい） プロトタイプベースが活きるのは、
クラスベースが到達できない領域なのよ。その最たるものがインスタンス
に独自のメソッドや属性を持たせるってやつで。
0498デフォルトの名無しさん
NGNGそれは別にクラスベースでもできるでしょう。
例： python, CLOS, 他のにもあるハズ
嬉しいのは「よりプリミティブである」って事だけなの？
0499デフォルトの名無しさん
NGNG0500デフォルトの名無しさん
NGNG0501デフォルトの名無しさん
NGNGまえにも見たな、この展開… (w
>>498
とりあえず、任意の instance から別の instance 作れるとか。
class と instance を兼用させるようなことができる。
501 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 14:29
>>500
> とりあえず、任意の instance から別の instance 作れるとか。
> class と instance を兼用させるようなことができる。
で、それも、どっちもclass baseでもできるんだよな。
502 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 17:46
501は
完全に「実現可能」のレイヤーを取り違えているんだよ。
そんなこと言ったら、Ｃでもマシン語だって可能だ。
その区別が付かない奴にいくら言っても堂々巡り。
503 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 17:54
>>498
だから、クラスベースの典型例やそこにおける反例として、
プロトタイプベースの素養を持つ CLOS だの Python をひきあいに
だすなっちゅうの。わざとか？
0502デフォルトの名無しさん
NGNG>>501
>で、それも、どっちもclass baseでもできるんだよな。
class baseだとclass定義したりそのclassの知識がないとできないから、
ただ「できる」っていうのは無意味。
C言語でOOできると言い張るのと同じ。
prototype baseはinstance を見るだけで追加できるという点で
大きく違う。
それが有効かどうかはともかく。
505 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 18:07
>>498
世に”簡潔は力なり”っていうからねｗ。
オブジェクトが扱える範囲でよりプリミティブであることは
いいことなんでないの？ようわからんけど。
506 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 18:18
>>504
> C言語でOOできると言い張る
それはprototype basedでclass basedもできると言うのと違わない
のかえ?それが許されるなら、class basedでprototype basedもできる
ってのも通るような…
507 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 19:16
形から入る人が多そうなスレですね
0503デフォルトの名無しさん
NGNG> オブジェクトが扱える範囲でよりプリミティブであることは
> いいことなんでないの？ようわからんけど。
小さい事は良い事!ってなミニマリストにはそうだろうがねぇ．Scheme なんかは
オブジェクトシステム自体が好きにすれば？ということでもっとプリミティブな
仕様になってるが，ミニマリストはあーゆうのが ｲｲ!! って方向にいっちゃうのかね？
でもさ，たとえば加算だけ用意すりゃ乗算は不要ってわけでもないだろ？プリミティ
ブだから良いって言われてもねぇ．なんか利点をガツーンとたのむわ．>>504 の解説
はわかりやすいなー．あとはそれがどのようにクラスベースよりｲｲのかを聞いてみたい．
509 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 21:43
>>508
でもさ、インスタンス特異的メソッドや属性がクラスベースで実現可能だからって
オブジェクトレベルでそれを実現するモデルを採用したオブジェクトシステムが
用なしってわけもないだろ？ なんだ自分で答えてるじゃん。それだよ、それ。
510 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 22:22
お、また堂々巡り繰り返してるな。
511 名前： デフォルトの名無しさん ：sage 投稿日： 04/03/25 (木) 22:23
>>508
そうさねぇ。
他人の作った生きているオブジェクトを
改良できることかなぁ。
.NETのClient side Validationはその具体例かな。
# ただインスタンスにメソッドを追加して回ってるだけなんだけどね。
0504デフォルトの名無しさん
NGNGそして、言語の動的側面を勘違いした椰子が現れて… まわるぅ～まわるぅよ(ry
513 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/25 23:46
一見ループに見えるが完全に同じではない．循環を断ち切れる事を願ってるんだYO!!
>>509 の意見とか初耳のような気がするぞ．他人の作った生きているオブジェクトを改良できる？
それはプロトタイプベースの特徴なのか？しかし浅学故，それがどうプロトタイプベー
スと関連するのかわからない．オブジェクトの受け渡しと特異メソッドが必要だがプ
ロトタイプベースとは関係ないんじゃ？と思うんだけど違うのかな．
今のところ
1. 「クラス」がないからシンプル
2. 「クラス」がなくても同等の機能（…なの？）
くらいしか理解してないんだが．どうもプロトタイプならではってウリが見えないわ
け．インスタンスのコピーはクラスベースだと苦労が多いけど，プロトタイプベース
にしたら楽になるのかな？コピーの深さの問題はどうしようもない気がするんだけど．
514 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:05
>>513
循環してるのは一部の人の頭の中だけだと思うよ。それを断ち切りたいなら、
何か言語いじってみれ。
0505デフォルトの名無しさん
NGNG>>513
プロトタイプベースでは、それなりの規模のシステムではたいてい、トレイトと呼ばれる
クラスベースのクラスと同じ枠組みを作ってそれを使っています。したがって、クラスが
なくても同等…というのは（解釈のしかたにもよりますが）当たりません。
こうした状況はクラスベースの Ruby が特異メソッドを用意しているのと似ていますね。
違いを際だたせるとすれば、Ruby にあるプロトタイプベースの側面は、特異クラスという
ちょっとトリッキーな方法で実現されているのに対して、SELF などでのトレイトは、言語
自体には手を加えずに実現されてているというところでしょうか。
余談ですが、SELF には Ｒｕｂｙ とまったく同様の目的と機能を持つミックスインすら
Ruby よりはるか以前からエンティティとして実装しています。それも、言語仕様には
まったく手を加えずに、です（もっとも、トレイトとミックスインの違いは、継承があるか
無いかの違いだけなわけですが…）。
何度か出ていますが、プロトタイプベースのメリットは、通常は言語仕様として出来合で
エンドユーザー（つまりプログラマ）が変更不能な部分を開放したかたちで処理系が提供
されている（できる）ことではないでしょうか。511 さんの言う「自分で改良できる」という
ニュアンスにはそんなところも含まれているように感じました。
これは、Smalltalk が処理系全体を Smalltalk 自身で記述し、エンドユーザーが自由に
閲覧、変更、拡張ができるようにしているのと似ていなくもないですね。ただ、SELF の
場合は、Smalltalk では変えられない部分も（たとえば、クラスとインスタンスの関係と
いったプリミティブな部分も） SELF 自体でトレイトフレームワークとして表現されている
ために、エンドユーザーが到達可能…というわけです。
Ruby の例に戻ると、仮に特異メソッドやミックスインの振る舞いに不満を感じても、まつ
もとさんを説得するまで仕様の変更は不可能です。しかし、プロトタイプベースなら自分の
好きに変えてしまえばよいのです。もっとも、これをミニマリズム、動的側面のメリットのとり
違い…と言われてしまえばそれまでですが。
0506この先、誰か持ってない？
NGNG>>508
Scheme が好まれるのはミニマルだからというのもあるけど、一番大きいのは
何かを特別扱いする事が少ないってことだと思うんだよね。言い直せば、言語
仕様による制限が取り除かれているってこと。
クラスは便利だけど同時に制約ともなるから、それを言語の根幹に据えるのは
嫌だなぁ。
517 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:46
>>512
動的じゃなきゃプロトタイプベースは成り立たないとおもわれ。
よって、動的であることの利点はプロトタイプベースの利点の一部に必ず含まれる罠。
518 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:49
このスレが活性化するのって、誰かがガンガってソースコードを晒した時か vs. クラスベース
の時かのどっちかだよな。クラスベースの時は大抵不毛な話題に終始するけど。
519 名前： デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:55
>>518
んだんだ。
traitsやmixin以外にどんな機能が実現可能か妄想したりするスレとかには……ならないなｗ
0507デフォルトの名無しさん
NGNG結構大変そうっていうかパフォーマンスが苦しそう。
0508デフォルトの名無しさん
NGNGうん・・・でもパフォーマンスを考慮した従来型の ORB や RPC に代わって
SOAP とか出てきてる世の中だからなぁ。
0509デフォルトの名無しさん
NGNGプログラム / プロトタイプベース・オブジェクト指向 - 情報
Lispがプリミティブなλ計算そのものだから何でもできるように、
プロトタイプは、OOについてプリミティブだから何でもできる、でいいの？
モノがほかのモノをプロトタイプとして持つってすごく変なモデルの気がするけど、
λ計算みたいに、数学的な意味を持ったモデルなんでしょうか。
プロトタイプがプリミティブたるOOモデルというのが多分数学的にあって、
クラスベースもその中にすっぽり入ってしまうんだと思います。
そういう、本物のOOの定義モデルが実はあるような気がします。
どの言語の何がOOの起源でObjectとはどうだこうだ、というレベルではなくて、
本物のOO定義モデルが。
制約は普通の手続き言語なんかそのものですよね。
チューリングモデルを制約することで使いやすくしているという意味で。
0510デフォルトの名無しさん
NGNGまんどくさいから、その辺からツッコミ直してみる。
> どの言語の何がOOの起源でObjectとはどうだこうだ、というレベルではなくて、
> 本物のOO定義モデルが。
prototype baseなモデルMpとclass baseなモデルMcを定義できたとして、
Mp上に仮想Mcを構築できて、なおかつ、Mc上で仮想Mpを定義できれば
どっちが本物とは言えなくなる罠。
と言うと、オッカムの剃刀と言い出す香具師がいるかもしれんが、
OOの全ての機能をObjectに集中させたのがprototype baseで、
オブジェクトの種類という視点では一番簡便になる。
一方、class baseではオブジェクトの生成とオブジェクトの働きを別々に記述するが
これは各機能をより純粋にモデリングしたということでもある。
> 制約は普通の手続き言語なんかそのものですよね。
> チューリングモデルを制約することで使いやすくしているという意味で。
これについては、そうは思わない。
チューリング機械は現代のプログラミング言語よりも表現上の制約を受けている。
つーか、チューリング機械なんて、ヘッドの左右への動きとヘッド位置にある
シンボルの置き換えでしか表現できないんだから、これ以上制約したら
ほとんど何もできなくなる罠。
0511デフォルトの名無しさん
NGNGこれが出来ないんじゃないのかな、
というのが上のレスと思われ。
> チューリング機械は現代のプログラミング言語よりも表現上の制約を受けている。
これについては、そうは思わない。
チューリング機械は現代のプログラミング言語の表現のどのようなモノも、
（表現が長たらしくなるが）表現できる。逆に、
現代のプログラミング言語はチューリング機械の表現のどのようなモノも、
（言語機能と同レベルで）表現できるとは限らない。
「言語機能と同レベルで」ってのはチューリング機械自体をエミュる層をわざわざ作らずに、ということ。
0512デフォルトの名無しさん
NGNG> > Mc上で仮想Mpを定義できれば どっちが本物とは言えなくなる罠。
>
> これが出来ないんじゃないのかな、
> というのが上のレスと思われ。
クラスベース環境上にプロトタイプベース環境を構築した例など腐るほどあるが。
> 現代のプログラミング言語はチューリング機械の表現のどのようなモノも、
> （言語機能と同レベルで）表現できるとは限らない。
現代風のプログラミング言語で実現できない例を挙げてみなよ。
つーか、とりあえず構造化プログラミングの論文でも読んでみれば？
0513デフォルトの名無しさん
NGNGああ、まったくそのとおり。ずばりエミュだもんな。ぼけてた。
これについては>>510の通り。
> 現代風のプログラミング言語で実現できない例を挙げてみなよ。
チューリングマシンのコーディングは漏れは出来ないけど、
関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？
0514デフォルトの名無しさん
NGNGLispだとプリミティブな計算モデルそのものだから、
任意の言語モデルを作って使えるみたいに、
プロトタイプはプリミティブなOOモデルそのものだから、
任意のOOモデルを作って使えるんじゃないかな、という妄想。
まあ、そのためには記法の問題っつうか、
Lispのマクロ相当がないとそのままは使えないけど。
0515デフォルトの名無しさん
NGNGこんなお仕着せの機構で成り立ったシステムがプリミティブだなんて
あり得ねぇよ。クラス機構と目糞鼻糞。
0516デフォルトの名無しさん
NGNG> 関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？
そんなことはチューリングマシンでもできん罠
0517デフォルトの名無しさん
NGNGだから相当するモノを作ることになる。
で、自分で作るんだから、
> 関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？
が出来るように作ればいい。schemeで似た事出来るし、出来るでしょ。
はNG？
0518デフォルトの名無しさん
NGNGプログラムコードの再利用機構って意味では、委譲ベースでも継承ベースでも
どっちでも良いな。相互排他的な物でもないし。
どっちも無いと困るけど。
肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
変数のスロットはインスタンスローカルで持てるのに、メソッドのスロットを
インスタンスローカルで持てないのって不便。
0519デフォルトの名無しさん
NGNG> 肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
> 変数のスロットはインスタンスローカルで持てるのに、メソッドのスロットを
> インスタンスローカルで持てないのって不便。
それ、Smalltalkでは動的にどうとでもできるって話が出てなかったか？
0520デフォルトの名無しさん
NGNGエミュるんだったら、プログラミング言語でもエミュるのアリにしないとな。
0521デフォルトの名無しさん
NGNG論理的な問題じゃなくて、実際的な問題。
チューリングマシンは概念がないから概念をエミュってなんぼのモノ。
プログラミング言語は、エミュらなくてもすぐ概念を使えるようにしているモノ。
用途で考えれば、プログラミング言語でもエミュるのは無意味。
エミュって概念壊したらプログラム言語の意味ないじゃん。
0522デフォルトの名無しさん
NGNG別クラスを生成して become するって話？
それともブロッククロージャを変数に代入してコールするとかかな。
0523デフォルトの名無しさん
NGNGどういう意味でキモなのかわからん。
委譲ベースとか継承ベースとかと関係が見えない。
とりあえず、リフレクション最強、
と言っておけばいいのか？
0524デフォルトの名無しさん
NGNG>> 肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
>どういう意味でキモなのかわからん。
>委譲ベースとか継承ベースとかと関係が見えない。
コードの再利用機構 ーー＞ どうでも良い
メソッドの再定義可能性 ーー＞ こっちが重要
リフレクションは実現方法の一つに過ぎないと思う。
0525デフォルトの名無しさん
NGNGいやいや、メソッド呼び出しとは何かの定義次第だから、
どっちもなくていいでしょ。それを定義できればいいんだから。
つまるところ、CLOSを産んだLisp最強ってことで。
0526デフォルトの名無しさん
NGNGなる。でもそれは必要なのは、
メソッド再定義可能性、じゃなくて、>>525の呼び出しの定義では？
委譲ベースでの定義 自分を捜して、なければプロトタイプから探す
継承ベースでの定義 自分のクラスを探して、なければクラスの親から捜す。
これ以外にもあり得るでしょ。
0527デフォルトの名無しさん
NGNGクラスベースもプロトタイプベースも目糞鼻糞。
0528デフォルトの名無しさん
NGNGなるほど、そうですね。
>それを定義できればいいんだから。
までは考えてませんでした。
>自分を捜して
というのがあれば自分的には嬉しいです。
Scheme みたいに、シンボルに束縛されているのが値か手続きか区別しない（
評価する時に S 式の頭にあれば手続きと看做される）ようなモデルがｲｲですね。
メソッドテーブルはクラスに属し、変数テーブルはインスタンスに属するという
のは実装上の都合ですよね。これは一貫性に欠けると思います。特にメソッドが
ファーストクラスなら、尚更。
0529デフォルトの名無しさん
NGNG>のは実装上の都合ですよね。
実装って言うか、それがクラス、なのかな？
うーん、クラスってなんだろ。
欲しいのは、
自分を捜して、なければ自分のクラスを探して、なければクラスの親から捜す、
っていう感じ？
しらんけど、Rubyってこんなんじゃない？
0530デフォルトの名無しさん
NGNG>>509 は >>506 の続きになるのかな。
0531デフォルトの名無しさん
NGNGメソッドに話を限れば、クラスは、オブジェクトにとって
・原則として変更が許されない
・無条件移譲先
ですね。逆に言えば、プロトタイプベースのオブジェクトにこのような
制約を課すことで、オーソドックスなクラスベースのオブジェクトが
できあがるわけです。縛りを緩くすれば、プロトタイプベースの要素を
盛り込むことができます。
0532デフォルトの名無しさん
NGNGさらに、自分が委ねられたメソッド起動リクエストについては、無条件委譲先
ではなく、あらかじめ別に用意した移譲先に委譲する…という縛りを設ければ
より完全にクラスベースの振る舞いをさせることができそうです。
たとえば、Smalltalk のクラスは（インスタンス）メソッドを持っていますが、
それらはインスタンスから委譲された場合のみ起動でき、自分で起動する
ことはできません。これは先の無条件委譲のしばりが効いていると考えるとうまく
説明できます。また、インスタンスから委譲されたが自分は持っていない
メソッドについては、ここで述べた「自らがレシーバでないときは、無条件
移譲先に委譲できない」という縛りから、二つある委譲先スロットのうち、
無条件移譲先には委譲できず、もう一方、つまりスーパークラスへ委譲せざるを
得ない、というふうに解釈すればよいわけです。
0533デフォルトの名無しさん
NGNGこのようなメソッドディパッチの観点から言うと、CLOS はそもそも
メソッドがオブジェクトに属しておらず、クラスベースでもプロトタイプ
ベースでもないので、ちょっと脇によけておいた方がよさそうですね。
0534デフォルトの名無しさん
NGNG0535デフォルトの名無しさん
NGNGクラスのインスタンスが常にひとつであるような制約を課すことで(見かけ上の)
プロトタイプベース・オブジェクトを実現できます。
たとえば、Smalltalk のようにクラス自身もオブジェクトで、かつ、メタクラスの
シングルトンであることが保証されている言語なら(非クラスの)インスタンスを
使わず、クラスを使うことでそのままプロトタイプベースプログラミングが(見かけ上)
可能です。
インスタンスに直接メソッドをもたせるような機構にしなければならないのならば、
制約を課すだけでは駄目で、薄いながらも何かしらレイヤーを書いてやる必要が
あるでしょう。
0536デフォルトの名無しさん
NGNG> Scheme みたいに、シンボルに束縛されているのが値か手続きか区別しない（
> 評価する時に S 式の頭にあれば手続きと看做される）ようなモデルがｲｲですね。
スレ違いだが、それはどうだろうね。
変数名とメソッド名への制約が増えるから、俺は嫌いだね。
0537デフォルトの名無しさん
NGNGインスタンスベースのスロットの定義等について、その機構をサポートする簡易な文法があって、
便利に利用できるってことが重要なんじゃない？
例えば、プロトタイプ言語で
human = [ kind: #human, bark() { print("I'm human");} ];
anAho = [ _proto: human, iq: 100, bark() : { print("My name is aho");} ];
とか２行でかけるものを、何行も文を連ねて書いて「出来ます」ってのはなんか違うっていうか・・・
0538デフォルトの名無しさん
NGNG簡単なオブジェクトを簡単に記述できるというのは、
スクリプト言語ならば重要な問題かもしれんが、
環境がベースになっている言語ではあまり本質ではないね。
つまり、スクリプト言語に使うのならメソッドを2,3定義するだけでいいものが多いから
1行や2行で書けるかどうかが問題になるが、もっと環境を使ってライブラリ蓄積
していくことを想定した言語では、そういった1行コードは問題ではない。
あと、Modula-3のopaque typeのように一見煩雑に見えるけど
言語機能としてはそれなりに洗練された結果というものもある。
0539デフォルトの名無しさん
NGNG流行ってないんでしようがないのだけれども、こういうのはある意味典型的な
プロトタイプ言語のコードなわけで、なんてのかな、>>535の前半のような発想よりは
むしろ↑の方で出てきたクロージャでインスタンスを実現するものの方が指向が
近しいような気がする、というか。。
>>536
>スレ違いだが、それはどうだろうね。
たぶん殆どのプロトタイプ言語でその区別は行われていないと思います。
好き嫌いはともかく。
0540デフォルトの名無しさん
NGNGあのー、いつの間にモデルの話からリテラル表現の話に飛んでいったのでしょうか？
あと、当然ながら処理系の設計の話もまた別の話だ罠。
0541デフォルトの名無しさん
NGNGところで、POOとUMLの関係ってどうなん？
0542デフォルトの名無しさん
NGNG> さらに、自分が委ねられたメソッド起動リクエストについては、無条件委譲先
> ではなく、あらかじめ別に用意した移譲先に委譲する…という縛りを設ければ
> より完全にクラスベースの振る舞いをさせることができそうです。
それだと、メタ方向の委譲とスーパー方向の委譲が混ざらないか？
0543!532
NGNGメタ方向ってインスタンス←クラス←メタクラスの関係の事？
スーパー方向はインスタンス←クラス←スーパークラスだよね。
>>532
で、>>532 が言ってるのは、foo.bar() で foo のクラス Foo がメソッド bar() を
持っていない時、クラス Foo は（Foo 自身のクラスである） MetaFoo に問い
合わせずに、別に用意されたクラス SuperFoo に問い合わせに行くようにする。
MetaFoo に行くか SuperFoo に行くかは、自分がレシーバかどうかで判断する。
・自分がレシーバの時は自分のクラスに問い合わせる（自分がクラスならメタクラス
に問い合わせる ーー そんなケースあるのかな？）
・自分がレシーバじゃない時はスーパークラスに問い合わせる
であってます？
自分がレシーバじゃないってどう判断するのかな？
プロトタイプチェーンが分かっていないので、変な事を言っていたら済みません。
0544デフォルトの名無しさん
NGNG言語って JavaScript 以外にあります？
0545デフォルトの名無しさん
NGNGそういう制御をしようとしたら処理系自体に手を入れないと話にならんでしょ
0546デフォルトの名無しさん
NGNGあるプロトタイプを共有しているオブジェクト全てにメッセージを送信する
機能を持っているプロトタイプベース言語ってありますか？
0547デフォルトの名無しさん
NGNG細かいようですが、SomeClass allInstances do: [:inst | inst somethingToDo] ですね。
で、本題は SomeClass allInstances みたいなものがあるか？
ということでよろしいですか？ それなら元祖的存在の SELF にすでに
browse childrenOf: obj
というのがあります。プロトタイプスロットに obj を束縛している
全オブジェクトをリスト(a vector) で返します。
0548デフォルトの名無しさん
NGNGどうもありがとうございます。
オブジェクト生成する毎に辞書に登録してるのかしらん。
プロトタイプベースの言語は個々のオブジェクトは野放し状態だと
思ってましたが、ある程度の管理はされているんですね。
0549デフォルトの名無しさん
NGNGん～、でも、Smalltalk においても #allBehaviorsDo: なんかは本来はオブジェクト全部に
問い合わせたりするのがスジだったりするので（高速化のための端折っていますが）
クラスベース、インスタンスベースに限らず、全オブジェクトがオブジェクトメモリ内にあるか、
さらに、それらにアクセスする手段があるか否かってところで、allなんたらな機能が存在しうる
かどうかが決まってしまうような気もします。
まあ、純粋なオブジェクト指向（そんなものがあればの話ですが…(^_^;)）を論ずるとき、
実装において、高速化や最適化がからむ部分は解釈が難しいですね。たとえば、
消えてしまったログの object-oriented pointer で表現されるオブジェクトには“状態”
はあるかないか…なんて話とかもそのたぐいだと思います。
0550デフォルトの名無しさん
NGNG> まあ、純粋なオブジェクト指向（そんなものがあればの話ですが…(^_^;)）を論ずるとき、
> 実装において、高速化や最適化がからむ部分は解釈が難しいですね。たとえば、
> 消えてしまったログの object-oriented pointer で表現されるオブジェクトには“状態”
> はあるかないか…なんて話とかもそのたぐいだと思います。
まったくです。正確には、オブジェクトの定義に「状態」は本質かどうか、ですね。
私としては、参照透明なオブジェクト世界が可能である以上は
「状態」は本質ではないと思うのですがね。
オブジェクトを「状態」と「機能」で定義しようという考え方というのは
ノイマン型計算機モデルをそのまま小さくして「オブジェクト」にしているんじゃないか
と思います。
0551デフォルトの名無しさん
NGNG結構好き。
オブジェクト指向言語は一時変数を作りまくるというイメージがあります。Smalltalk とか、
文法的には返り値を使うスタイルでも全然問題無さそうなのになぁ。
Lisp と Smalltalk を足して２で割った様な言語が欲しい。Self がそうかと思ったけど、
どうなんでしょう？
0552デフォルトの名無しさん
NGNG0553デフォルトの名無しさん
NGNGdynamic binding な言語が好きなもので。すいません。
0554551
NGNGhttp://slate.tunes.org/
以前このメールを見た時は、サイトに繋がらなかったのに。
ttp://www.sra.co.jp/smalltalk/SML/archives/2002-October/005955.html
0555デフォルトの名無しさん
NGNGC++ の operator() および、 boost::function などの汎用関数オブジェクトは、
型にとらわれない柔軟な仕組みだと思う。C++ は静的でありながら、工夫次第で
動的拡張も可能なモンスター言語だとおもう。
myObject.Connect( "Proc", MyFunction ); // MyFunction を スロットにセット
( myObject->*"Proc" )( 24 ); // MyFunction 呼び出し
とかも出来る。しないけど。
0556デフォルトの名無しさん
NGNG0557デフォルトの名無しさん
NGNG0558デフォルトの名無しさん
NGNGttp://research.sun.com/self/release_4.2/release.html
05591
NGNG0560デフォルトの名無しさん
NGNGおまえら。
0561デフォルトの名無しさん
NGNG0562デフォルトの名無しさん
NGNG一応、あるにはあるのですが…。古いので動かすのは難かしいかも。
ttp://www.gliebe.de/self/
0563デフォルトの名無しさん
NGNG0564デフォルトの名無しさん
NGNG0565デフォルトの名無しさん
NGNG一応IoやSmalltalk（Squeak）でもいいんじゃない？
0566デフォルトの名無しさん
NGNG海外で結構人気らしい。
http://www.prothon.org/index.html
0567デフォルトの名無しさん
NGNGこら! Smalltalkはクラスベースだろ。それをプロトタイプベース
に改造した「始祖」がSelfだ。
0568デフォルトの名無しさん
NGNGC＃って死滅する理由がないよね！ Part4
http://pc5.2ch.net/test/read.cgi/tech/1042464104/639
0569デフォルトの名無しさん
NGNGタイルスクリプティング（だっけ？）の部分じゃないの。
0570デフォルトの名無しさん
NGNGそれはSmalltalkじゃなくてSqueakな…
いってみれば「Cは統合ヘルプ環境がいい」と同じぐらい変。
0571デフォルトの名無しさん
NGNG>>565 に Squeak って書いてあるじゃん。
0572デフォルトの名無しさん
NGNGできていない罠。
eToysはSmalltalk言語で記述されているが、Smalltalk言語とは別物の
言語処理系。プロトタイプベースだし、変数には型があり、if-then-elseの
条件分岐構文もある。
ふつう、Squeakと書けば（Smalltalkが併記された場合はなおさら）「Squeakシステム」を、
Smalltalkと書けば「Smalltalk言語」をイメージさせるから「Smalltalk（Squeak）」と
書いてもSqueak eToysを意図しているとは受け取られにくい…
のであります。
0573デフォルトの名無しさん
NGNG匂わせたかったのかと思ったよ。まぁ、好意的な解釈かもしれんが。
0574デフォルトの名無しさん
NGNGむしろ？ わざわざ？
0575デフォルトの名無しさん
NGNG0576デフォルトの名無しさん
NGNG05771
NGNG最近Haskell勉強してるんですけど、
「頻繁に使用する少数の道具」が揃っているところが強みだと感じています。
再帰系の高階関数とかコンビネータとか。
そういう厳選された道具がオブジェクト指向の世界にも存在するのかなぁ。
もしあればそれを探し出して、組み込んだ言語ならクラスベースに匹敵するかも。
Lightweight Language が流行っているように
如何に簡単に多くのことを行えるか、がこれからの言語争いで重要だと思います。
# 言うまでもないけど
0578デフォルトの名無しさん
NGNGdiablo2 のjspというBOTはjavascript。
まあまあ使いやすかった。
プロトタイプベースである必要はあんまない気がするが。
0579デフォルトの名無しさん
NGNG0580デフォルトの名無しさん
NGNG0581デフォルトの名無しさん
NGNGボタンや IMG の挙動を変えるのにいちいち別クラスにしたくないな、確かに。
0582デフォルトの名無しさん
NGNGやっぱJavaScript程度のものが妥当なんだと思った。
LispやSmalltalkみたいな変則的なものは知ってる人じゃないと近寄りがたい。
手軽にtarget.xとかドット表記でオブジェクトを指定できるのもいい。
なんだかんだ言ってもCかPerlなら知ってる人多いからね。
jspのスクリプトがあそこまで普及したのはライブラリの質の高さもあったけど、
構文的なわかりやすさが影響してると思う。
プロトタイプベースとあんま関係なくてごめん。
0583デフォルトの名無しさん
NGNG0584デフォルトの名無しさん
NGNG何か興味あるところで“お題”を出してもらえればすぐに。
でなければ、普段使っているクラスベースで数行のサンプルを
提示してくれれば、それと同等のものを書きます。
0585デフォルトの名無しさん
NGNGINU:
[ "WAN! WAN!" mise. ] naki<
[ "GATU GATU" mise. ] tabe<
tabe.
naki.
INU! NEKO<
NEKO:
tabe.
naki.
[ "NIAO NIAO" mise. ] NEKO.naki<
NEKO.naki.
INU.naki.
実行結果
GATU GATU
WAN! WAN!
GATU GATU
WAN! WAN!
NIAO NIAO
WAN! WAN!
0586デフォルトの名無しさん
NGNGstatic int resNumber;
public:
virtual void hosyu() = 0;
virtual int resWrite(std::string contents, bool isSage = true) = 0;
};
class PrototypebaseOOThread : public Thread2ch {
void hosyu()
{
・・・
}
int resWrite(std::string contents, bool isSage = true)
{
・・・
return ++resNumber;
}
};
int main()
{
PrototypebaseOOThread *anObject = new PrototypebaseOOThread();
anObject->resWrite("ぬるぽ");
delete anObject;
return 0;
}
//コードでスレッドの保守を表現する感じでお願いします。
//言語名もかいてくれると(゜д゜)ｳﾏ
//で、585氏早速ありがとうございます
0587デフォルトの名無しさん
NGNGそれのドコがプロトタイプベースやのん？
0588デフォルトの名無しさん
NGNGというわけで >>585 を上でちらりと出た Io で書いてみる。
Dog := Object clone do(
bark := method( "WAN! WAN!" linePrint )
eat := method( "GATSU GATSU" linePrint )
)
Dog eat
Dog bark
Cat := Dog clone
Cat eat
Cat bark
Cat bark := method( "NIAO NIAO" linePrint )
Dog bark
Cat bark
実行結果
GATSU GATSU
WAN! WAN!
GATSU GATSU
WAN! WAN!
NIAO NIAO
WAN! WAN!
犬の派生に猫ってのも妙だけどなー。
0589585
NGNGほとんど知る人のない梓弓スクリプトという言語です。
なんとか直訳的に写すとこんな感じかなあ。でも、
>>587>>588に同感で、プロトタイプベースと
クラスベースでは、書く時の考え方も変わってしまうと思う。
---
@! Thread2ch< Thread2ch:
0 resNumber<
[ ] hosyu<
[ contents< isSage< 0 ] resWrite<
Thread2ch! PrototypebaseOOThread< PrototypebaseOOThread:
[
(略)
] hosyu<
[ contents< isSage<
PrototypebaseOOThread.resNumber resNumber<
(略)
resNumber 1 age, resNumber> ] resWrite<
[
0 "ぬるぽ" PrototypebaseOOThread.resWrite.
0 ] @.main<
---
梓弓はごらんの通りの後置記法で、「<」は代入、「>」は値の取出し、
「@」は始原オブジェクト、「!」はコピーの作成、など。
>>588
猫じゃなくて普通にポチとかにすると、「ポチ is a 犬」だから
クラス・インスタンス関係みたいになってちょっとかな…と。
0590デフォルトの名無しさん
NGNGプロトタイプベースは、親のスロットを変更すると子にまで影響及ぶんでしたっけ？
0591デフォルトの名無しさん
NGNGデリゲーションチェインがあればどうなるかは考えればわかるだろ
0592デフォルトの名無しさん
NGNG言語によりけりじゃないのかなあ？
JavaScript なら影響及ばなかった気がする。
梓弓だと影響及ぶけどね。
INU.tabe.
INU.naki.
NEKO.tabe.
NEKO.naki.
[ "PAKU PAKU" mise. ] INU.tabe<
[ "KYAN KYAN" mise. ] INU.naki<
INU.tabe.
INU.naki.
NEKO.tabe.
NEKO.naki.
実行結果
GATU GATU
WAN! WAN!
GATU GATU
NIAO NIAO
PAKU PAKU
KYAN KYAN
PAKU PAKU
NIAO NIAO
0594デフォルトの名無しさん
NGNGなにかと思ったら、プロトタイプベースで書いて欲しいコード
だったんですね。仮想関数あたりはモディファイしてあります。
#Io
Thread2ch := Object clone
Thread2ch resNumber := 0
Thread2ch resWrite := method(contents, isSage,
return(resNumber += 1))
Thread2ch hoshu := method(
return(resWrite("保守",self)))
ProtoBasedOop := Thread2ch clone
ProtoBasedOop resWrite("１げっと",Nil)
==> 1
ProtoBasedOop hoshu()
==> 2
ProtoBasedOop resNumber
==> 2
Thread2ch resNumber
==> 0
0595デフォルトの名無しさん
NGNG0596デフォルトの名無しさん
NGNG05971
NGNGてこんな単純じゃ言語の特徴あまり出ませんね。
dog = {
bark: ({arg:[x]; do:[println "WAN! WAN!"];} eval);
eat: ({arg:[x]; do:[println "GATSU GATSU"];} eval);
};
dog eat bark();
dog bark ();
cat = dog + {};
cat eat ();
cat bark ();
cat bark = {arg:[x]; do:[println "NIAO NIAO"];} eval;
dog bark ();
cat bark ();
0598デフォルトの名無しさん
NGNGぐぐったら下のほうに出てきたけど、>>596の類いだな。
まあなんか高い志掲げてるし、将来に期待すれ
0599デフォルトの名無しさん
NGNG人少なすぎで少し困ってる
微妙にプロトタイプベースじゃないが勘弁
# Petit Script
Root
create -> Dog;
Dog
<- bark { System puts "Wan! Wan!" }
<- eat { System puts "Gatsu Gatsu" }
bark
eat
create -> Cat
bark
eat
<- bark { System puts "Niao! Niao!" }
bark
eat;
Dog
bark
eat;
0600599
NGNG# 実行結果
Wan! Wan!
Gatsu Gatsu
Wan! Wan!
Gatsu Gatsu
Niao! Niao!
Gatsu Gatsu
Wan! Wan!
Gatsu Gatsu
From: 今新しい言語を作ってます
ttp://pc5.2ch.net/test/read.cgi/tech/1054580836/l50
0601586
NGNGJavascriptあたりから出直してきます。＿|￣|○
0602デフォルトの名無しさん
NGNGググって出てきたの？
「梓弓スクリプト」でググったら該当無し
「梓弓 スクリプト」でググってもそれらしいのは見当たらず
「梓弓 script」も同様
「梓弓」だけじゃワケワカメだった。
ちょっと興味があるんでキーワード教えてくださいな。
0603デフォルトの名無しさん
NGNG「梓弓 スクリプト」でぐぐると、
三つめくらいに時候の挨拶っていうのがあって、
そこからリンクたどると見つかるよ。
0604デフォルトの名無しさん
NGNGずっと時間が経ってからスレを見る人のために
ちゃんとリンクしたほうが良いと思いませんか？
梓弓について
http://gr.vxx.jp/azusayumi.html
リンクに関する見解
http://gr.vxx.jp/link.html
0605デフォルトの名無しさん
NGNGRuby厨と言われるかもしれないけど、RubyのようにクラスベースOOの人でも
違和感無く扱えるような構文の方が良くない？
0606デフォルトの名無しさん
NGNGもっと具体的に
0607デフォルトの名無しさん
NGNGありがとん
0608デフォルトの名無しさん
NGNGスクリプトに限らず俺言語ってのは基本的にオナニーだからだろ。
0609デフォルトの名無しさん
NGNG必要だとは思う。かといって Smalltalk みたいに英語に近くするとネイティブ以外に
分かり辛い所も。
0610デフォルトの名無しさん
NGNGってかRubyはクラスベースじゃないの？SeRubyのこと？
漏れはある程度記号が使われるコードのほうがいいなぁ。JavaやPythonとかだと記号が少ないと感じる。
0612デフォルトの名無しさん
NGNGJavaScript程ではないけど
0613デフォルトの名無しさん
NGNGこのｽﾚに Ruby 知らないﾔﾂは居ないと思うが。
0614デフォルトの名無しさん
NGNGﾉｼ
名前を知ってはいるけど見たこと無い
使わないし
0615デフォルトの名無しさん
NGNGてかWinとかだと自前で入れないと入らんか
0616デフォルトの名無しさん
NGNGやっぱどこでも使えるJavaScriptがいいよ
0617デフォルトの名無しさん
NGNGttp://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html
0618デフォルトの名無しさん
NGNG0619デフォルトの名無しさん
NGNG具体的にはどんなふうに？
0620デフォルトの名無しさん
NGNG0621デフォルトの名無しさん
NGNG今までずっと「tetris使って説明しだした辺りからうさん臭さを感じた」と読んでた。
0622デフォルトの名無しさん
NGNGつーか、最初から2-3人で回し書きしてるのがミエミエだったろ(藁
プロトタイプ最強君と、クラスベースも等価君と、バランス君。
0623デフォルトの名無しさん
NGNG0625デフォルトの名無しさん
NGNGみたいなコードキボン。
0626デフォルトの名無しさん
NGNG言語システムのローレベルをくみ上げていく（っと言うかブートストラップと言うか）の段階が一番興味深い結果出すと思うが。
0627デフォルトの名無しさん
NGNGどんな感じ？イメージ沸かぬ。
0628デフォルトの名無しさん
NGNGクラス型の言語だとObjectがすべての原型->そのObjectのClassのメタクラスの->Object
みたいな循環部分を最初にどうやってくみ上げるかってお話があるじゃないですか。
プロトタイプ型言語だと自分を派生させる機構は最初何から始めるのだろうって当たりが面白いんじゃないのって事なんで
あんまり深く考えてたわけじゃないです。
小生４年くらい前にpureオブジェクト指向言語をclassベースでやったときにその基底部分のくみ上げが非常に面白かったんで
同じようにプロトタイプ型言語でも興味深い（言語の性格に依存した）立ち上げ方法があるんでないのかって事です。
0629デフォルトの名無しさん
NGNG0630デフォルトの名無しさん
NGNG0631デフォルトの名無しさん
NGNGプロトタイプではいかにあるべきか考えるのが面白いって事？
0632デフォルトの名無しさん
NGNG俺は、ある言語が扱う範囲を１つの世界と見立てると、基幹の定義はその世界の外に作っちまうな
あたかも“初めから存在してました。深くは考えないでください”って感じに
0633デフォルトの名無しさん
NGNG↓
誰も使いたがらない
↓
死滅
このプロセスで大筋間違いないよね
0634デフォルトの名無しさん
NGNGははは君の理論で行くと全ての言語が一度に滅ぶでないかw
完全にカスタマイズできるマシン語が最強なのだよ、ってな感じにね
あふぉかと
0635Aransk
NGNG２．不自由だから誰が使っても大差ない。
３．誰でも使い出す。
ってのはどうなんでしょう？
デザインパターンにしても一握りのチョンの
後をポチが追いかけるスタイルですよね。
自由にすると大多数のポチは何をしたら良いのか
さえ分からないから、言語は自由度を制限せざる得ない。
ただ問題はワタクシのように単なるポチの
くせにチョンを真似て自由な言語を好むタイプが
存在するから話がややこしくなる。
（我流で無茶苦茶書くから…書いても一応動くから…
本人でもメンテ出来ないコードを誰がメンテできるのか…）
これが大規模開発にチョン言語が使えない理由では
ないでしょうか？
0636デフォルトの名無しさん
NGNG他人の指向にどうこう言う筋合いは無いし、事実御前の考えも一理あるが、
少なくともデザパタに関しては認識そのものが間違ってる
よく勉強しなおす事
0637Aransk
NGNGデザインパターンを示されても理解が困難な
ポチにパターン自体を創造出来るかどうか？
これを問題にしておるのであります。
チョンが道筋をつけその後、ポチの程度に
よって追いかけかたが変わります。
新たなデザパタを作れるポチも居れば
利用するだけのただ乗りポチも居る。
一生オブジェクト指向に縁無きポチも存在する。
但し理解して利用しないのと、理解出来ずに
利用できないのとでは雲泥の差がある。
理解して利用しないのは十分チョンの
見識有りと考えます。チョンを超えている
可能性も否定できません。
0638デフォルトの名無しさん
NGNG>やっぱどこでも使えるJavaScriptがいいよ
JavaScriptってもうプロトタイプベースじゃないんじゃない？
0639デフォルトの名無しさん
NGNGちなみに「クラスがない」ってよく言われるけどありゃ嘘で、
本当は「クラスを言語が用意する必要がない」（つまり、
他の基本的言語機能で必要なら実現可能）ってだけの話です。
実際、SELF にも NewtonScript にもクラス（SELF では
トレイトと呼ばれているけど）はあって、言語仕様では
重要な役割を演じています。
0640デフォルトの名無しさん
NGNG変数のスコープと評価順序に癖のある言語ですが、プロトタイプベースらしいので。
REBOL []
Dog: make object! [
bark: does [print "WAN! WAN!"]
eat: does [print "GATU GATU"]
]
Dog/eat
Dog/bark
Cat: make Dog []
Cat/eat
Cat/bark
Cat/bark: does [print "NIAO NIAO"]
Cat/bark
Dog/bark
Dog/eat: does [print "PAKU PAKU"] ; 親スロットを変更してみる
Cat/eat
Dog/eat
0641デフォルトの名無しさん
NGNGインスタンスベースとか、オブジェクトベースのほうが良い
と思います）の要件は「インスタンスがメソッド（メンバ関数）
や属性を *クラスに依存せずに* 持てること」に尽きるでしょう。
0642デフォルトの名無しさん
NGNGGATU GATU
WAN! WAN!
GATU GATU
WAN! WAN!
NIAO NIAO
WAN! WAN!
GATU GATU
PAKU PAKU
: は代入宣言, / メンバの参照。
does は、引数なし関数を生成する関数。makeは、newとかclone相当。
>>590
REBOLでは影響なし。Prothonでは影響がありました。
0643Aransk
NGNG>プロトタイプベース・オブジェクト指向とは
>http://sumim.no-ip.com:8080/wiki/493
によれば
>「インスタンスがメソッド（メンバ関数）
>や属性を *クラスに依存せずに* 持てること」
ではなく、問題は本来持てないはずが持ててしまう
ことにあるのではないでしょうか？
インスタンスは持てちゃ駄目なんです。
退歩を進歩と錯覚しているに過ぎない。
Rubyに特異メソッドを持てなく
することや、カプセル化を厳しくしろ
って言うほうが逆に大変なんじゃなか
ろうか。
ルーズ化するほうがイージーだってこと
もある。
0644デフォルトの名無しさん
NGNGつまり
・ ECMAScript や JavaScript は問題だから使うべきではない。
・ DHTML で使う際にも、<input onClick="hoge()"> なんて書けちゃダメで、ちゃんとクラス化して
class HogeButton { onClick() { hoge();} }; <input class="HogeButton"> 等と記述できなくてはおかしい
ということですね。
同意しておきます（ｗ
0645デフォルトの名無しさん
NGNG0646デフォルトの名無しさん
NGNG>>「インスタンスがメソッド（メンバ関数）
>>や属性を *クラスに依存せずに* 持てること」
>ではなく、問題は本来持てないはずが持ててしまう
>ことにあるのではないでしょうか？
>インスタンスは持てちゃ駄目なんです。
関数/メソッド自身もオブジェクトな言語では、
関数を変数やフィールドにいれたりする事は自然な事なのですが。
0647デフォルトの名無しさん
NGNGにおいてはインスタンスはクラス（すなわち、それが属する型）の支配下にあって
しかるべきだし、各々が独自の関数（インターフェイス）を持つなどということは言う
までもなく、クラスをしても動作中に仕様を換えるなどということはあってはならない
こと。したがって、インスタンスベース（と、それにより実現されるメリット）なんて、
とんでもない…ということになる。
ところが、ケイの“メッセージ指向”オブジェクト指向の世界では、考え方がかな
り違う。オブジェクトはソフトウエアを構成する一部ではあるが、それ単独では
非力で意味のない部品であってはならない。それぞれが独立して機能する
小さなコンピュータであるべきだと彼は言う。＊１ これらが高速のネットワーク
で接続され、ソフトウエアは機能する。彼の設計したSmalltalkでは（残念ながら
クラスベースで、インスタンスはその支配下にあるが、それでも）クラスもまた
オブジェクト、つまり、別のクラス（メタクラス）のインスタンスであることや、動作
を止めずにクラス定義の変更を通じてオブジェクトの振る舞いを変えられること
などに彼のオブジェクト指向が目指していたところの片鱗を見ることができる。＊２
もちろんこれは、前者の立場の者、有名なところではメイヤー、の目には、
いたずらに混乱を招くだけの、無用の（あるいは代替可能な）仕様にしか見えない。＊３
このように、オブジェクトが自らの振る舞いをクラスに依存せずに決められることについて
の評価は、よりどころとするオブジェクト指向が、クラス指向なのか、メッセージ指向なの
かによって違ってくる。インスタンスが“本来”どうあるべきか、もしかり。
＊１ http://www.akademia.co.jp/Smalltalk/SML/archives/SRA.archives/2003-October/006339.html
＊２ ただし、ケイはインスタンスベースに対する態度を保留している。
＊３ 「オブジェクト指向入門」 ISBN: 4-7561-0050-3
0648デフォルトの名無しさん
NGNG> ＊２ ただし、ケイはインスタンスベースに対する態度を保留している。
LISP的でカオティックすぎると批判していなかったか？
0649デフォルトの名無しさん
NGNGよければ出典を。 まあ、いかにもらしくて言いそうなことだけれど。ｗ
念のため、保留との解釈の根拠はこちら。
http://www.google.co.jp/search?q=cache:WbjukQKKfwAJ:glab.cs.uni-magdeburg.de/
~croquet/downloads/Croquet0.1.pdf
0650デフォルトの名無しさん
NGNGクラス（←これもまた何かのインスタンス）を動的に変更できない方が不自然な感じがする。
Lispで何でも再定義できるのも同様。
システム全体がとてもステートフルなものになってしまうという問題は確かに大きいのだけれど、
dll hell等でどうせシステムはとてもカオティっクでステートフルになるんだから別にいいか。
いや、そんなことないか。如何様にも変更可能なクラス（インスタンス）はいいとして、何か不動の
インタフェイス的なものが無いとやっぱり辛いな・・・
0651デフォルトの名無しさん
NGNGJavaとかの「普通」のクラスベースOO言語に対して、プロトタイプベースってどの辺にメリットがあるのかな。
便利な場合もあるだろうけど、ただ便利じゃなくてせめてそれがクールに感じられるコーディングにならないと
言語としてメリットとは言い難い気がする。
0652デフォルトの名無しさん
NGNG委譲を使うコードがむちゃくちゃシンプルになる。
ttp://homepage.mac.com/mkino2/oop/chainOfResp/
0653デフォルトの名無しさん
NGNG> Smalltalk流にパーシスタント・オブジェクトの集合してシステムが出来上がってるものの場合、
> クラス（←これもまた何かのインスタンス）を動的に変更できない方が不自然な感じがする。
それで実際、クラスどころかオブジェクトのサイズから属性やメソッドまで動的に
変更できるわけです。
0654デフォルトの名無しさん
NGNGできれば書籍が一番うれしいのですが。
googleじゃ引っかからなかった（英語圏は試してない）
0655デフォルトの名無しさん
NGNGミニマルではないけれど、インスタンスベースを語る前に、少なくとも
これだけには目を通しておくべきかと思います。
ttp://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html
インスタンスベースの考察については、英語でちょっと高い本ですが
A Theory of Objects (ISBN: 0387947752)
ttp://www.amazon.com/exec/obidos/tg/detail/-/0387947752
がそれなりにページを割いていて、比較的詳しいです。これを読むと
クラスベースとプロトタイプベースに本質的な違いはなにもないことも
分かります。
0656デフォルトの名無しさん
NGNG立場を分けて評価する必要があります。たとえば、インスタンス変数を
持たず、スロットを振る舞いと属性で共有することについては、名前の
衝突の問題が生じることがすでに分かっています。（つまり、スロット
アクセスを多態させるときに getXXX などと別名を設けないといけない）
こうした問題はメッセージ送信重視の立場から来るもので、インスタンス
ベースであることとは関係ありません。
SELF はメッセージ指向寄りの（しかしメッセージ指向とは違う、単に
メッセージ送信重視の）立場から、Smalltalk の実装に対して生じた
疑問、あるいは想定しうる理想像を具現化して見せたものとみることが
できます。その結果生じたもののひとつがインスタンスベースだと
考えておくのが無難です。つまり、インスタンスベースの特徴は SELF
に見ることができますが、SELF の特徴すべてがインスタンスベースに
当てはまるわけではないということです。
インスタンスベースの他に、SELF の副産物としては、コスト高で最適化
が難しいメッセージ送信の行きすぎた(笑)徹底により、VM の高速化技術
が生まれたことが挙げられます。これは Strongtalk という静的型チェック
機構を持つ Smalltalk の派生物を経て、現在、Java VM に役立てられて
います。
0657デフォルトの名無しさん
NGNG> getXXX などと別名を設けないといけない
スミマセン。これ嘘です。getter ではなく setter のしかも、SELF では
なく Io の言語仕様上の問題を思い違いしておりました。忘れてください。
0658Aransk
NGNG考えていること：
言語論的に申し上げればフィンランド語は動詞の変化
だけでも30型あります。ヨーロッパ系言語のなかでは
最も複雑な文法体系を有しております。
ご承知の通りフィンランドの教育水準の高さは世界の
他の国を圧倒しております。つまり使いこなせれば
言語は精緻であればあるほど頭脳を進化させます。
コミュニケーションの幅が広がる次第です。
西サモア諸島の言語は現在形しかありません。
プログラミング言語と同じです。
従ってプログラマーの頭脳水準は…。
なんてことを言いたい訳ではありません。
つまり精密なルールは文明の進化に負っております。
で、話をインスタンスにメソッドやフィールドを
持たせることに戻ります。
クラス概念の精緻化というパースペクティブから解釈
するとそれは単にルールを破っていることに過ぎない。
また、LispやSchemeの言語文法自体を変化させる
マクロは言語自体を破壊することになる。
これは不自由で精緻なルールがあるから
人間の頭脳は進化するというパースペクティブから
の意見です。
0659デフォルトの名無しさん
NGNGProgramming as an Experience: The Inspiration for Self
にも出てくるけれど、
「スロットで振る舞いと属性を共有する」
つまり
「スロットの中身が値ならそれを返して、
メソッドオブジェクトならそれを実行する」
というやりかただと、
メソッドオブジェクトを値としてほしい場合に困るっていう問題があります。
これに対してSelfではmirrorオブジェクトというのを使うみたいです。
0660デフォルトの名無しさん
NGNGおお。SELFってこういう物だったんだ。参考になるなあ。
0661デフォルトの名無しさん
NGNGCoRなんてごくたまに使う程度のモンじゃない？
LispのLambda式みたいに、CoRベースの世界が構築できるなら別だけど、
クラスベースOO言語とくに静的型付の普通の言語のメリットには遠く及ばないよね。
0662デフォルトの名無しさん
NGNGちょっとびっくりしちゃったわけね…。
0663デフォルトの名無しさん
NGNG現状のクラス・ベースでは、そういった場面をデザインパターンや
クラス・システムの拡張で対応しているが、(そのシステム数だけ、それを特徴とした新たな言語を生み出している)
プロトタイプでは一般的な概念の枠内で拡張し対応できる。
例として、AOP拡張とかプロトタイプ・ベースの言語で提示してみるのはどうでしょう?
例えばJAVAがソース or バイトコード変換といった手段で実現している事を、
プロトタイプ・ベースでどれだけ簡単に出来るかというのを比較してみると面白いかもしれません。
0664デフォルトの名無しさん
NGNGclassがfirst class objectであるかどうかの問題とゴッチャになってないかい？
0665デフォルトの名無しさん
NGNGとはいえAOP関連だと、特定のインスタンスのみにコード挿入するとか、クラスベースでは出来ない
ものも簡単にできるのも確か。
でも、さんざ既出のDHTMLのようなものが簡単に書けるというのがプロトタイプ言語の特徴だと思う。
クラスを沢山作らなくても、複数のimgタグでonClickの動作を変えられるし。.NetのSystem.Windows.
Forms以下の各種コントロールにイベントハンドラを記述するというアーキテクチャなんかも、これは
prototype言語の守備範囲なんじゃないか？とか思うし。
0666Aransk
NGNG>C++ < Java
>CommonLisp < Scheme
>Smalltalk < Self
>と思うわけですよ．この気持わかるでしょ？
その気持ちはすっごく分かる。
幼稚園時代だけど。W
不思議と実用性は前者が高いんですよね？
C++とJavaのケースを除き…というか
本来の意味の実用性で言えば個人的には
C++とは思いますが。
理由として考えられるのは
アカデミックな理論整合性より現実の
ソリューションは複雑であるということが
一つ。
もう一つはプログラマーの専門性の問題です。
誰でもとっつき易いものでは食えない
が、しかし、あまりに少数しか分からないもの
でも職業として成立しない。
このパースペクティブから、プロトタイプ言語の
自由度は協業度の面でマイナスとして
作用しないのでしょうか。
つまり作った奴しか分からないというか
作った本人もどのインスタンスに細工したのか
忘れてしまうとか。
0667デフォルトの名無しさん
NGNGごっちゃ通貨、それは包含関係にあるのでは？
何か問題が？
0668デフォルトの名無しさん
NGNGクラスをfirst class objectとしているクラスベース言語が多数ある以上、
>>663は完全にトンチンカンなわけだが。
0669663
NGNGfirst class objectって時点で、
多くのプロトタイプ(インスタンス)ベースの実装と本質的には同じものになるだろうけど。
クラスやオブジェクトの拡張がクラス・ベースの概念の枠内でどのように扱われているかという点において、
クラス・ベースの言語ではメタ・プログラミングが必要な場面で、
プロトタイプ(インスタンス)・ベースでは自然に備わっている特徴で解決出来る。といった主張でした。
0670Aransk
NGNG重みや深みは付加されません。
敢えてプロトタイプベースの命綱でなる
オブジェクトに対するメッセージパスについて
伺いたい。
本質的な機能として引数を指定して関数を
呼び出すこととの差異はなんでしょうか？
つまり敢えて擬人化した名前を付することに
よる効果の方が実質を上回っていないの
でしょうか。
0671デフォルトの名無しさん
NGNG>クラス・ベースの言語ではメタ・プログラミングが必要な場面で、
>プロトタイプ(インスタンス)・ベースでは自然に備わっている特徴で解決出来る。といった主張でした。
例示してください。
0672Aransk
NGNGリンクを外しておられませんでしょうか？
06731
NGNG>インスタンスは持てちゃ駄目なんです。
なんで？
駄目な理由を述べよ。
>誰でもとっつき易いものでは食えない
これ、クラスベースに対するプロトタイプベースのルールの少なさに対して言ってるんだよね。
バッドノウハウでしか食ってけないプログラマなんていらないよ。
このスレもいつの間にか1年経ちましたねぇ。
0674Aransk
NGNG型生成と実動プログラムを分離したところにある訳です。
従ってインスタンスが自ら変形して新たなインスタンスを
生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような
倒錯した状況を生み出すことになるのです。
２．従ってプロトタイプベース言語は愛玩用のToyProgramを
作成することにその長所を発揮すべきではないでしょうか。
成熟社会はますます個人の自由な暇潰しを求めます。
そのニーズにぴったり合致した言語ではないでしょうか。
と、まぁ敢えて批判的に申せばこうなります。
ところで１っつぁん、>>670に対する
貴方ご回答を期待しておるのですが？
0675デフォルトの名無しさん
NGNGクラスベースはオブジェクト指向の誕生と同時に誕生したと思っていたが
考え方が根本的に違う
プロトタイプベースの利点は、既存のオブジェクトを（ある程度まで）自由に弄れる事
例えば、HTML で記述された既に画面上に存在するボタンなどに追加の挙動を割り当てられる等
クラスベースだと、予め全てのボタンを定義しておかなければいけないという制約が付く
オブジェクトを変更させない方に特化するか、変更させる事に特化させるか
どちらも同様にニーズがあることは自明で、どちらが優れているかは議論すべきじゃない
と俺は思う
……というか、クラスベースとプロトタイプベースのどちらが優れているかなんて
日本語と英語のどちらが優れているかを議論するようなもんだろ？
0676デフォルトの名無しさん
NGNGというか、>>670 の『擬人化』の意味が良くわからんとですが
0677デフォルトの名無しさん
NGNG日本語の方が優れています。
これは全世界で一致している見解です。
と言ったら？
0678デフォルトの名無しさん
NGNG0679デフォルトの名無しさん
NGNG0680デフォルトの名無しさん
NGNGすごいなぁ
幾ら優れている言語が出来ても、初めのうちは糞言語ですか
0681デフォルトの名無しさん
NGNG考えることをしなくなった人間ってのはもうおしまいかと。
0682デフォルトの名無しさん
NGNG0683デフォルトの名無しさん
NGNGそれいったら「構造化サイコー」になっちまうが……
いくつのプログラムがCで書かれていると思っているのかね？
PerlやPHPみたいな「ちょっとオブジェクト指向」もたくさんあるし
0684デフォルトの名無しさん
NGNGやたらと。それがなにか？
0685デフォルトの名無しさん
NGNGOOPLとOOを混同しちゃだめだよ。
0686デフォルトの名無しさん
NGNG0687デフォルトの名無しさん
NGNG数えるほどしかないよ
不可能な数じゃない
がんばれｗ
0688デフォルトの名無しさん
NGNGproto
↓
object
を
proto
↓
ウィルス
↓
object
にするだけで全体感染する
0689デフォルトの名無しさん
NGNG>インスタンスが自ら変形して新たなインスタンスを生成することは
インスタンスが「勝手に」変わるわけじゃねえって。
プログラマがインスタンスを加工して目的のインスタンスに
近づけているんじゃねえかよ。
>鯛焼きの鯛が金型無しで鯛焼きを作るような
はあ、型や設計図が無いとモノを作れないのかな？Aranskは。
プログラマは鯛焼きだけ作れりゃいい、つうわけでもないだろうに
鯛焼きの金型じゃ、お好み焼きは作れんわ
>２．従ってプロトタイプベース言語は愛玩用のToyProgramを
あと、
・アイディアを検証するための「実験プログラム」
・実際に動かしながらプログラムを作成する「成長プログラム」
なんかも、柔軟性と即効性を考えるとちょうどいいかもねぇ
まあ、職人＆日曜大工向けのツールだわな。
コーダーには触らせたく無いねぇ
0690デフォルトの名無しさん
NGNGwでvi *.rbとかやってるとああ、どっかではたらいてんだなと。
0691デフォルトの名無しさん
NGNG0692デフォルトの名無しさん
NGNGどうやってプロセスに潜り込むの？
0693デフォルトの名無しさん
NGNG実際Smalltalkみたいな環境だと簡単にできる
0694デフォルトの名無しさん
NGNGばーか
superclass
↓
ウィルス
↓
subclass
にするだけで全体感染しますよ
0695692
NGNGSmalltalkはクラスベースでつな。
クラスベースもプロトタイプベースも関係ないような……
0696デフォルトの名無しさん
NGNG> 生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような
> 倒錯した状況を生み出すことになるのです。
考え方がクラスに縛られてますね。
クラス・ベースで考えるならこの場合はfactoryパターンを参考にするといいと思います。
プロトタイプベースで言い直すなら、鯛焼きの *インスタンスに当たるもの* はその鯛焼きの複製です。
金型のインスタンスが鯛焼というのはクラスベースの概念で解釈した場合で、
プロトタイプの世界では、タイヤキとその金型はそれぞれ独立したオブジェクトであり、
金型の複製が鯛焼になるという事はありません。
インスタンスという概念自体がclassベースのものである事に注意して下さい。
つまり、誤解の原因はインスタンスだと思っていたそれが、プロトタイプの世界ではインスタンスではなく複製である事。
オブジェクトが存在するためにクラスといった概念を必要としていない為、
インスタンス生成といった作業自体が必要ないのです。
敢えて、このクラスやインスタンスという概念をプロトタイプ・ベースに導入するなら、
金型オブジェクトに鯛焼オブジェクトの複製を生成するようなメソッドを持たせるとわかりやすくなると思います。
この場合でも、金型はクラスといった概念ではなく、金型自身が具象化したオブジェクトであり、
金型にも細工を施し、別の形のたいやきを生成したりする事が出来ます。
クラスを、オブジェクトの定義宣言みたいに考えると、
定義がころころ変わったり、鯛焼がある日突然卵焼になってしまうと困るといった主張は理解できます。
が、これはクラスベースで思考しているからであって、プロトタイプ・ベースでは、
金型が変わったからといって、すでに作られた鯛焼まで変わってしまうとは限らないのです。
ところで、擬人化して語ると、複製を作るといった作業が身近な例に当てはまらないので、
メタファを作るのは難しいかも知れませんね。
コンピュータ上の概念で説明するなら、データのコピーで済ませられるのだけど。
0697デフォルトの名無しさん
NGNGプロトタイプベース言語のメッセージパッシング時の最適化に関する論文とか資料へのポインタをご存じの方がいたら示唆お願いしますです。
NewtonScriptもどき作ってるんですけど_Parentの_Parentの………とセレクタ追いかけ回すのめちゃくちゃ重くないですか？
0698デフォルトの名無しさん
NGNG問題ない。俺が作ったときは proto を追尾しなかったw
最終的に clone 時にスロット全部コピーしたからなぁ
まあ、俺も知りたいところではあるが
0699デフォルトの名無しさん
NGNGそこはオレも悩んでいるんだけど、やっぱりキャッシュするしか無いかな……
freeze - thawを導入して、protoの変更タイミングを通知するようにするか、
protoが変更されると全てのキャッシュが無効化されるようにするか……
0700デフォルトの名無しさん
NGNGSelfの論文が山程ある。
0701デフォルトの名無しさん
NGNGttp://research.sun.com/self/papers/papers.html
のImplementationに関する論文でしょう(読んでないので違ってるかもしれない)。
Type inferenceについての論文も関係あるかも。
0702697
NGNG大学に聴講生制度あったはずだから登録して図書館で探すしかないのかorz
ACMの論文集って普通の図書館でも取り寄せ効きますか？
0703デフォルトの名無しさん
NGNG0704Aransk
NGNG>実はプロトタイプベースは、クラスベースと相反するものでは
>なく、クラスベースより一段階プリミティブなものだと
>考えると、つまり、プロトタイプベースにいろいろな機構
>（トレイトとしてクラス）や制約（独自メソッドの追加や
>再定義、インスタンス変数の追加を禁じる）を設けることに
>よってできたのがクラスベースだと解釈すれば何ら問題が
>ないことが分かりました。
これって卓見だと思う訳ですよ。
優劣の問題ではなく、クラスベースってプロトタイプ
ベースより進化した形態なんだと思う。
つまりコピー機能（型生成）と実プログラム機能を分離する
ことでより構造化されたプログラミングパラダイムを
生み出した訳です。つまりある自由度、（古くはgoto文）などを
規制することでより間違いの少ない安全度の高いプログラミング
レベルを目指してきました。
個人的になんでも出来ることと、協調してプログラミング作業を
する場合とは違うということです。
さらに出来ることと出来ないこととは違います。
必ずしも前者が後者をスパーシードしているとは言えないのです。
擬人化とは：
例えばメッセージパッシングってオブジェクトが
オブジェクトにメッセージを送っているようなイメージが
あります。しかしCの関数呼び出し、やCobolのサブルーチン
の呼び出しと実態機能的にそう変化はないのではない
でしょうか。
つまり単なる名前だけによるプログラミング機能のラッパー的
要素が含まれているように思えるが…。
0705デフォルトの名無しさん
NGNG大部分の論文はciteseerその他からpdf版も手に入るみたいです。
0706デフォルトの名無しさん
NGNG> さらに出来ることと出来ないこととは違います。
ここが藁い所なのか？
0707デフォルトの名無しさん
NGNGごく一般的な言葉だと思う。
もちろん本質的ではないし、このスレでも使っているのは１名のみに見える。
あと
＞必ずしも前者が後者をスパーシードしているとは言えないのです
これは誰しも同意するだろうけれども、何かを含意していないと無意味な主張。
で含意している内容が「クラスベースってプロトタイプベースより進化した形態なんだと思う」
ならば、「そうですか」としか言い様がない。確かにDHTMLの保守性は悪い。
爬虫類は両生類より進化している、という主張は可能だろうけれども、
サンショウウオ本人やサンショウウオ飼育者にとって、その主張に何か意味があるか、
というとかなり疑問。鳥は恐竜よりも進化している？でも鳥よりも恐竜の方がずっとクールでカッコイイよ。
07081
NGNG>>670
> 本質的な機能として引数を指定して関数を
> 呼び出すこととの差異はなんでしょうか？
> つまり敢えて擬人化した名前を付することに
> よる効果の方が実質を上回っていないの
> でしょうか。
どうもメッセージ送信と関数呼び出しの違いを
気にしているようですが、それとプロトタイプベースとの関係がわかりません。
メッセージ送信モデルと関数呼び出しモデルの一番重要な違いは
受け手であるプログラマの解釈である私は思います。
中でやってることは同じ場合が多いことはあなたも知っているかと。
あなたの言う「本質的」や「実質」が何を指しているのかがわからないので、
うまく答えられてないですね。すみません。
>>674
> １．ご承知の通りクラスとインスタンス概念の導入は
> 型生成と実動プログラムを分離したところにある訳です。
> 従ってインスタンスが自ら変形して新たなインスタンスを
> 生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような
> 倒錯した状況を生み出すことになるのです。
倒錯した状況ねぇ…それがインスタンスはメソッドを持てちゃ駄目の答えですか。
それはつまり世の中のほとんどのプログラムがクラスベースで書かれているから
という答えと変わらないんじゃないですか？
何故それが「倒錯」と言えるのかを示さない限り。
クラスベース的な鯛焼きのメタファをプロトタイプベースに当てはめてみて
こいつはおかしい! と自信たっぷりに言われましてもどう対応していいやら…
0709689
NGNG>ベースより進化した形態なんだと思う。
進化<->退化という同一ベクトルにある話じゃないと思うんだけどね
自分だけだろうけど、
プロトタイプベース
「全てを持つ」要素を組み上げてシステムを構築
->細胞的、生体組織的
柔軟な、増殖的
クラスベース
全てを記した図面から要素・組織・システムを作り出す
->機械的、人工物的
効率的、最適な
といったイメージがあるなあ
0710デフォルトの名無しさん
NGNG0711デフォルトの名無しさん
NGNG>進化<->退化という同一ベクトルにある話じゃないと思うんだけどね
特殊化と言うんだと思う。
ある差異を「特殊化」というか「進化」というかは、純粋に発言者の観点の違いでしかないのだけれども。
すぐ死んでしまう脊椎動物は原生動物よりも進化していると言えるのか、とか、
ウイルスは（その方向はラディカルだけれども）途轍もなく進化した究極の生命形態じゃないのか、とか。
後段のイメージの方だけれども、Smalltalkはそれなりに柔軟で増殖的だと思う。C++ も。Javaは（ｗ
漏れはたぶんSmalltalkについてはVM全体で一つの「インスタンス」とイメージしてるっぽい。
既存のクラスも勝手にガチャガチャ変えるから。
0712Aransk
NGNG>> さらに出来ることと出来ないこととは違います。
>ここが藁い所なのか？
プログラマの解釈性に甘えて言葉だけが実体以上に
イメージを増大させていないでしょうか？
というのが論点の一つです。
例えばRubyで継承したクラスから上位クラスの
Privateメンバーにアクセス「出来ない」ようにする
ことは「出来ない」のではないでしょうか。
それが欠点ではなく売りになることがおかしい
と考えるのです。
またPerlでThere is not more than one way to do it.
という売りがありますが、単に言語仕様の輻輳に過ぎない
とも言えます。
プロトタイプベース言語に敢えて批判的な立場で
意見を申し上げておりますが…ってゆうか
これまでの２ちゃんねるの発言では全てその
スタンスを保つようにしております。
メリットの影にあるデメリットにも
光を当てて総合的、多面的な評価こそ
望ましいと考えるからであります。
0713Aransk
NGNG>実はプロトタイプベースは、クラスベースと相反するものでは
>なく、クラスベースより一段階プリミティブなものだと
>考えると、つまり、プロトタイプベースにいろいろな機構
>（トレイトとしてクラス）や制約（独自メソッドの追加や
>再定義、インスタンス変数の追加を禁じる）を設けることに
>よってできたのがクラスベースだと解釈すれば何ら問題が
>ないことが分かりました。
この卓見を書いた人はもうこのスレには
参加してないのでしょうか？
是非ご意見を頂きたい。
0715デフォルトの名無しさん
NGNGどうしようもない馬鹿だとわかった。
0716John
NGNGhttp://mput.dip.jp/?date=20030912
を読んでプロトタイプベースを理解したつもりになった。
一番重要なのは
どのようにポリモーフィズムを実現するか
ということにある。
JavaやC++なんかの普通のOOというのは
木構造型に派生していく継承と、それらをまとめるインターフェースによって作られる。
一方で、プロトタイプベースというのはスロットというパーツの
組み合わせて作る。
ここで一番の違いはアクセス保護された変数の扱いにある。
継承の概念があるOOはprotectedというアクセス保護が有効になる。
一方で、プロトタイプベースでは
プロトタイプ間の共通変数を作れないデメリットがある。
しかし、プロトタイプ間は独立となっているため、切り離しが可能となる。
つまり、好きなプロトタイプを組み合わせることができるというメリットがある。
0717John
NGNGクラスというのは
メソッドと変数がクラスの中で閉じていることを意味する。
オブジェクト指向では継承という概念で拡張し、
インターフェースという概念でグルーピングする。
一方、プロトタイプ指向でも
クラスはメソッドと変数で閉じている。
それらを足し合わせることで、新しいクラスを作ることができる。
この言い回しから思いつくのは
プロトタイプベースでは型によるエラーチェックができないことにある。
つまり、実行してみるまで、ポリモーフィズムできるかどうかがわからない。
一方、オブジェクト指向言語では、実行前に型のチェックをするために
コンパイル時にエラーチェックができる。
0718デフォルトの名無しさん
NGNGクラスベースにおけるクラスとインスタンスの区別が無くなった物がプロトタイプベースだと考えるとわかりやすいよ
クラスの継承もインスタンスの生成も、プロトタイプベースにおけるクローンで纏められている
コンパイル時にクラスが既に決定しているクラスベースでは、クラス≒型に見立てて型チェックできるけど、
プロトタイプベースでは実行中にインスタンスが生成されるため、機構が単純だが型チェックできない
0719John
NGNGコンパイル時の型によるエラーチェックは非常に強力だと思うことと、
親クラスを切り替えたいケースはまれであること
（特に動的に切り替えたいケースはまれだ）
から、プロトタイプより、オブジェクト指向をお勧めする。
0720John
NGNG>クラスベースにおけるクラスとインスタンスの区別が無くなった物がプロトタイプベースだと考えるとわかりやすいよ
これはおかしいと思うよ。
結局のところ、インスタンスの定義をしなくちゃいけないわけで、
その定義の仕方が違うだけ。
クラスの継承とインターフェースで定義するのが、オブジェクト指向
（インターフェースは純粋仮想クラス？だからクラスの一種か）
クラスの足し合わせでインスタンスを定義するのがプロトタイプベース
0721John
NGNGおかしいっていうのは、それじゃ理解できないって意味ね。
間違ってるって意味じゃないです。
0722デフォルトの名無しさん
NGNG0723デフォルトの名無しさん
NGNG0724John
NGNGSmallTalkは確かに（ｒｙ
だから使われな（ｒｙ
0725デフォルトの名無しさん
NGNG全然違う
このスレの前のほう読め
0726デフォルトの名無しさん
NGNGそれは静的型付けと動的型付けの違い
0727デフォルトの名無しさん
NGNG> （インターフェースは純粋仮想クラス？だからクラスの一種か）
全然違う。
0728デフォルトの名無しさん
NGNG説得力ないよｗ
0729デフォルトの名無しさん
NGNGなんのうまみも無いので、プロトタイプベースは動的型付けでいいと思う。
逆に、オブジェクト指向は型を厳密に決めることができるので、
そのメリットは活かさないに越したことは無い。
と思うんだけど。
誰かメリットデメリットをまとめてくれ。
参考程度にどぞー
http://www.atmarkit.co.jp/fjava/rensai3/devworks05/devworks05_2.html
0730デフォルトの名無しさん
NGNG正解は、インターフェイスはクラスではない。これで満足か？
0731デフォルトの名無しさん
NGNG結論だけではなくて、その理由を書こうね。
0732デフォルトの名無しさん
NGNG正答を知りたきゃ金払えと。
0733デフォルトの名無しさん
NGNGこれ以上変更する必要がないということがわかってても
それを固定化できないってのは辛いよね
例えばあるメソッドを持つ親が必須のオブジェクトなのに
「無い場合」という本質的に無意味な分岐を作る必要が出てくる
メソッドを呼ぶときはそれを毎回チェックしないといけない
静的クラス指向やインタフェースを持つ言語なら
そのメソッドないとそもそも実行すらできない、
って風に別の保障を付けられる
静的なプロトタイプベースは作れないかね
0734デフォルトの名無しさん
NGNGそれに合致しないオブジェクトをそのインタフェースを持つオブジェクトの
プロトタイプには選択できないようにするとか。
まあこの手段でもプロトタイプ設定時「選択できなかった場合」という
分岐は存在してしまうけど、
毎回メソッドごとに不安要素を抱えるよりは健全であると思う
インターフェース内での最適化も出来ると思うし
0735デフォルトの名無しさん
NGNGインターフェースを仮初の型とみなして、
そのぶんの動的なメソッドディスパッチを全て省略できるとか
プロトタイプベースの正攻法の最適化って、やっぱ消極的なキャッシュぐらいだろうし
静的な型やインターフェースを持ち込むことでかなり強力になるとおもうんだよね
0736デフォルトの名無しさん
NGNG0737デフォルトの名無しさん
NGNGちょっとは考えないのかな
考えないんだろうね
まそういう人間はそうやって思いつきだけで行動して
そのうち人殺しまでやった後気付くんだよな
「愚かだった」って
0738デフォルトの名無しさん
NGNG0739デフォルトの名無しさん
NGNGプロトタイプベースがいつまでも軟体動物である必要はない。
甲冑でも着て体当たりもできるような頑丈な体を望むオブジェクトも必要だろうし
メソッドがないだけて終了する恐れのあるプログラムをジャンボ機や管制塔に
納品するわけにいかない
オブジェクトの状態を定数化できれば似たようなことができそうだがね
0740デフォルトの名無しさん
NGNG0741デフォルトの名無しさん
NGNG理由ねえ・・・sunのサイトからJava Language Definitionでもダウソして読め。
0742デフォルトの名無しさん
NGNG0743デフォルトの名無しさん
NGNG動的型＝データに割り当てられた型
静的型＝変数に割り当てられた型
でおｋ？
0744デフォルトの名無しさん
NGNGコンパイル前に型が決まっているか、（静的）
実行してみるまで型がわからないか（動的）
という違いでいいと思うよ。
静的なOOはそのオブジェクトの実態がなんだかはわからないけど
基底クラスなりインターフェース（純粋仮想クラス）なりがわかっているから
メソッド呼び出しが成功することが保証されてる。
0745デフォルトの名無しさん
NGNG基本になってるのは
データとそれに関連するメソッドをパッキングしましょうってこと。
そして、その共通部分を抜き出して定義することで、
１．共通部分を1箇所に記述する
２．メソッドディスパッチ（ポリモーフィズム、動的バインド）で処理フローを簡略化する
ということだと思うんだけど
ここまでは正しいのかな？
0746デフォルトの名無しさん
NGNG動的・型チェックだと思ってた
0747デフォルトの名無しさん
NGNGPTBではクラスの足し合わせでそこら辺を記述する。
1つ疑問なのは
データとメソッドを「１つに」パッキングすることが目的なのに
PTBにおけるクラスの足し合わせだと
データは分断されたままなのではなかろうか？
getter/setterを用意すればいいんだろうけど、それって
面倒な気もする。
いまいちプロトタイプベースのうまみがわからない。
誰かわかる人解説してくれないか？
0748718
NGNGすまぬ、ちょっと文面が正しくなかった
＞クラスベースのクラス継承とインスタンス生成の区別が無くなった物がプロトタイプベース
ちなみにこれは Io のドキュメントに書いてあったような希ガス
07491
NGNGどちらかと言えばプロトタイプベースの方がオブジェクトを重視していると思いません？
0750デフォルトの名無しさん
NGNGそれは思いませんが上段には賛成ですね
0751デフォルトの名無しさん
NGNG>データは分断されたままなのではなかろうか？
super::memberとかproto->memberすればいいんじゃないの？
アクセス制限してるならともかく、
親見に行くのにgetter/setterなんて用意する必要ないでしょ
名前探索の方法は言語ごとに異なる要素だから一概にはいえないけど
そういやprivateとかpublicとか属性はあるのかね
0752デフォルトの名無しさん
NGNGどうせ実装上の副産物みたいなものでプロトタイプベースの本質じゃない気がするし、
はやいとこそんな機能切ったほうがいいんじゃないのかね。
protoがhogeだったのに
いきなり
proto := hage
されていいことなんか何もなさそうだよ？
0753デフォルトの名無しさん
NGNG柔軟性を保つとトリッキーなことが出来るとは思うけど、
プロトタイプの本質≠プロトが改変可能かどうか
だと思う
親の挿げ替えは、正直あまり使わないな
0754デフォルトの名無しさん
NGNG0755デフォルトの名無しさん
NGNG親の挿げ替えができる／できない
親の変更が子に反映される／されない
0756デフォルトの名無しさん
NGNG0757デフォルトの名無しさん
NGNG他の変態プロトタイプベース言語のクセ話しても通じないこと多いし
javascriptは素人でも扱えるし
0758デフォルトの名無しさん
NGNGECMAScriptスレ行け
「メジャーだから～～の実装こそが○○を現わす」と騙るのは不毛だから止めようぜ
0759デフォルトの名無しさん
NGNG話はそれからだ
0760デフォルトの名無しさん
NGNGクラスの挿げ替えができる
クラスの変更がインスタンスに反映される
な言語はあるでよ
0761デフォルトの名無しさん
NGNG前半賛成、後半反対。
プロトタイプベースもクラスベースも等価であって、
どちらが優れているかは、それ以外の技術要素(型システムやメタプログラミ
ング、リフレクション、例外、継続など)や処理系や開発環境との
「組み合わせの妙」のほうがずっと重要。
0762Aransk
NGNG立場から述べます。
ttp://mput.dip.jp/?date=20030912より引用：
>実行時に動的に先祖クラス(に相当するもの)が変更できます
>実行時に動的にメソッド定義やメソッド除去ができます。
プログラムは作成者の意思を反映させるものという
観点からして上記の操作が動的にできるメリットって
なんでしょうか？
>動的すぎてわけが分からなくなります :-)
これはstaticかつpublicに卓見だと思うのです。
0763デフォルトの名無しさん
NGNGメリットとして上の方ではCoRが挙がってたけどそれっておまけだよな。
あとGUIのボタンとか、インスタンス固有の振る舞いが多くかつ混乱が起きにくい場合、か？
それのJavaのinterface+無名クラスとかC#のdelegateとかより優れてるトコってなんだろう？
モデルがシンプルできれい、というだけ？
0764デフォルトの名無しさん
NGNGスロットの変わりに無限個 (なお、変数名が重ならないように) 作成したとすると、
プロトタイプベースっぽくなるような気がする
0765デフォルトの名無しさん
NGNGプログラム内で一個しか作らないオブジェクトに、わざわざ新しいクラスを作りたくない
とか
0766デフォルトの名無しさん
NGNGプログラム内で一個しか作らないモノのクラスをつくるのと
プログラム内で一個しか作らないモノのオブジェクトをつくるのと、
何が違う？
0767デフォルトの名無しさん
NGNGsingleton でぐぐるように
という誘導は置いておいて、例えば Web ページ上にボタンが配置されているときに、
そのボタンにメソッドを追加するのはプロトタイプベースのほうがやりやすいよな
0768デフォルトの名無しさん
NGNGクラスが動的な存在であれば、POOもCOOも大した違いはないんじゃないかと。
COOではお仕着せのクラス機構の代わりに、POOではシンプルな委譲機構が提供されているというだけで。
POO知らずにJavaScriptやったとき、「なんじゃこの手抜きなOO機構わ。ハハハ」と思った記憶があります。
それを踏まえてPOOのメリットって言うと、どうなんだろう。
0769デフォルトの名無しさん
NGNGsingleton くらい知ってるわヽ(`Д´)ﾉｳﾜｧｧｧーﾝ!!
わざわざsingletonなんてしないで無名クラスでやりゃ、
どのみち定義書いてオブジェクトにセットするって手間は変わらんだろっつってんだよ。
おまけにJava/C#なら型チェックもしてくれるぞ。
0770デフォルトの名無しさん
NGNG0771デフォルトの名無しさん
NGNG0772デフォルトの名無しさん
NGNGプログラムは作成者の意思を反映させるものという観点からして、
オブジェクトを直接記述できるプロトタイプベースのほうが
クラスを介してしか記述できないクラスベースよりも
その意思を直接反映させることができる、
ということにも気付かないのかなあ。
あいかわらず過去ログでの議論にも目を通してなさそうだし。
0773デフォルトの名無しさん
NGNG0774デフォルトの名無しさん
NGNGそれはつまり、>>763の最終行でFA、ということでよろしいか？
Aranskのような脳味噌クラス漬けが大半を占める世の中ではメリットとは言えまいて。
0775デフォルトの名無しさん
NGNG> それはつまり、>>763の最終行でFA、ということでよろしいか？
全然違うよ。
むしろプロトタイプベースの良いところはdirty hackingな状況で発揮される。
モデルがsimple&cleanであることと、記述が直接的であることは全然別問題。
0776デフォルトの名無しさん
NGNGクラスベースは「設計図から機械を作る」のに対し、
プロトタイプベースは「いっぱいあるジャックにプラグを色々組み合わせていく」イメージとか妄想してみると
クラスベースのほうが綺麗に作れるけど、プロトタイプベースのほうがごちゃごちゃしているが簡単に作れる？
0777デフォルトの名無しさん
NGNGdirty hackingな状況で発揮されるってことは、
書ける・書けないってとこが最重要で、それもさっくり書けるところがポイントだと思うが、
>>769の通り、クラスが動的なら、クラスベースもプロトタイプベースもさほどの違いはないのではないか？
0778デフォルトの名無しさん
NGNG0779デフォルトの名無しさん
NGNGツールキットだからな
0780デフォルトの名無しさん
NGNGclass の意味は『分類』だから、別にオブジェクト指向に縛られてなくてもいいんじゃないか？
07811
NGNGプロトタイプベースだと綺麗に記述できると思います。
使ったことないけどDOMで便利だっていうのはそういうことですよね。
例えばEmacs Lispなどのいじくり回す必要があるアプリレベルを叩く言語とか。
システムを一から作り上げるのはクラスベースの方がいいかもしれないけど、
システムを表面から操作するのはプロトタイプベースの方がスマートだと思います。
システムの上で別のシステムを動かすことまで考えると一概には言えませんけど。
Smalltalkがクラスベースなのはそのせいかなぁ。
システム記述とシステム操作の言語を統一することを考えた場合、
プロトタイプベースよりクラスベースの方が良さそうだということかなぁ。
それともプロトタイプベースなど考えつかなかったのか。
0782デフォルトの名無しさん
NGNG> システムを一から作り上げるのはクラスベースの方がいいかもしれないけど、
> システムを表面から操作するのはプロトタイプベースの方がスマートだと思います。
その通りだと思う。
あるいは、記述するだけならプロトタイプベースのほうがhandyでdirectに記述できる。
が、他人に理解してもらおうと思ったらクラスベースのほうが整理しやすいんじゃないかな。
> Smalltalkがクラスベースなのはそのせいかなぁ。
> システム記述とシステム操作の言語を統一することを考えた場合、
> プロトタイプベースよりクラスベースの方が良さそうだということかなぁ。
> それともプロトタイプベースなど考えつかなかったのか。
Kay的には、例えばeToysのようにクラスベース上にインスタンスベースな環境を
構築すればいいだけという(無意識の)見切りがあったんじゃなかろうかと思う。
だが、一般のOO屋は、そこにあるクラス群こそがSmalltalkだと思ってしまった
のではないかと。
0783デフォルトの名無しさん
NGNG思想や書き方云々は金にならん。
0784デフォルトの名無しさん
NGNG>>783
2chで文句垂れてても金になりませんよ。
0785デフォルトの名無しさん
NGNGYou show: theCode
0786デフォルトの名無しさん
NGNG0787デフォルトの名無しさん
NGNG0788デフォルトの名無しさん
NGNGおい、Ruby よりも低級な言語が存在していないぞ
0789デフォルトの名無しさん
NGNGRuby ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ 788 名前： デフォルトの名無しさん [sage] 投稿日： 04/12/30 20:13:59
>>787
おい、Ruby よりも低級な言語が存在していないぞ
0790デフォルトの名無しさん
NGNGRuby ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ 788 名前： デフォルトの名無しさん [sage] 投稿日： 04/12/30 20:13:59>>787
おい、Ruby よりも低級な言語が存在していないぞ
0791デフォルトの名無しさん
NGNG0792Aransk
NGNGIoってどうしたら日本語通じるの？
「Io>」プロンプトのあと色々と
やってみたがどうもうまく行かない。
アドオンを付加すれば一応ユニコード
OKみたいなことをHPには書いてあるよう
だけど…。
0793Aransk
NGNGどうも良く分からないんですが、プログラミング
パラダイムそのものを考えた場合に
「main メソッドの喪失」
ってどうなんでしょうねぇ。
これはプロトタイプ言語だけではなく
スクリプト系言語全般に言えることで
すが、プログラムの構造化の観点からすれば
逆流はしてますよね。
0794デフォルトの名無しさん
NGNG当たり前だろ？ 構造化とは逆方向を行くのが関数指向や論理指向、もろもろの非手続き指向なんだし
それから、構造化がプログラムの質を上げるというのは必ずしも正しいことじゃないよ
0795デフォルトの名無しさん
NGNGぬるーよろ
0796689
NGNGmain メソッドが消失しているのではなく、トップレベルがmain メソッドに
なっているだけのこと。
スクリプト系は頭から逐次処理されることを想定しているから、
わざわざスタート地点を指定する必要が無いだけですな。
メリット
・プログラムするときに、逐次処理部分と定義部分を分けて考える必要が無い
・処理系を作るのが（逐次処理だけで済むので）ラク
デメリット
・（どの部分をあらかじめ処理していいのかのヒントが少なくなるので）
最適化しにくい
純粋関数型でも同様だと思う。
0797デフォルトの名無しさん
NGNGという関数を定義しないと動かないし、結局は処理系の設計者がどう考えて設
計したか、ってだけだと思うんだがな。
つうかAranskにマジレスしても無駄。
0798デフォルトの名無しさん
NGNG> 結局は処理系の設計者がどう考えて設
> 計したか、ってだけだと思うんだがな。
だよね。
少なくともOOやクラスベース/プロトタイプベースとは直交した概念だと思う。
0799Rubyist!
NGNG十把一絡げの愚図Java,C++,Perlみたいなカス言語フリーク野郎が
Ruby作者matzのような結果を出した人間と自分との格差を認められず
おこがましくも精神的に一矢報いようとするために
仰々しく「批評」とか名付けた浅ましい自己主張で攻撃して
自尊心を慰めてるにすぎない。
実際問題として、お前みたいな奴が考えてるほど
批評された側の役に立ってるわけがないだろ？ボケが。
その口から出るクソが誰かに感謝でもされたか？ああ？
自意識過剰甚だしいんだよ、この自己愛のボケ奴隷が。
数倍マシ？寝言は寝て言えよこの恥知らず野郎。
ネットで万能感むき出しにしてオナってんじゃねーよ。
批判する野党が重要だぁ？ﾌﾟ
公明党にでも投票してろ白痴野郎。
0800デフォルトの名無しさん
NGNGすみません、SELF, NewtonScript, IO, soopy マンセーなんですけど……
（実際に使っているわけじゃないけどね……）
>3-4見た？
0801デフォルトの名無しさん
NGNG３行目まで読んだ。
＞Ruby作者matzのような結果を出した人間
「ような」だと、係る部分が不確かなので、「ように」のほうがいいと思われ。
0802Aransk
NGNG>・プログラムするときに、逐次処理部分と定義部分を分けて考える必要が無い
>・処理系を作るのが（逐次処理だけで済むので）ラク
逐次処理と定義部分がごっちゃになって可読性に欠けることが
一つさらに、
処理系に対しても負荷が大きいような気がします。
つまりmainを無くしたことのメリット、デメリットを
冷静に見る必要があると思う次第です。
（RubyやMatzに対して特に含むところはありません。
くれぐれも誤解しないで下さい。）
0803デフォルトの名無しさん
NGNG> 逐次処理と定義部分がごっちゃになって可読性に欠けることが
「定義する」という動作を逐次処理しているだけの話でしょ。
> 処理系に対しても負荷が大きいような気がします。
どうして？詳細きぼん、ってaranskに言ってもしょうがないか。
0804デフォルトの名無しさん
NGNG>プロトタイプベースだと綺麗に記述できると思います。
具体例きぼんぬ
妄想で終わらせると机上の空論で終わるよ。
rubyにmainがあろうがなかろうが変わらないでしょ。
最初に必要な全ての関数（クラス）定義を一度読み込まなきゃいけない。
あるいは、関数が現れたら探さなきゃいけない。
rubyだと、ある関数が呼ばれた時にそれがどこの記述されているかを
探さなきゃいけないんで、（最悪見つからないことも・・・）
結局のところ、一番最初にがばって読み込んでから、
処理を開始するのが普通のやり方だと思うけど。
>逐次処理と定義部分がごっちゃになって可読性に欠けることが
そんなことは言語仕様で定めなくても、誰もやらん。
>処理系に対しても負荷が大きいような気がします。
気のせいだろ。
個人的にはJavaの言語仕様がスマートでかっこいい。
0805689
NGNG>逐次処理と定義部分がごっちゃになって可読性に欠けることが
ああ、スマン。確かに可読性は落ちるけど、書くのがラクなのよ。
取りあえず動くもの作って、その後にリファクタリングで可読性を上げる
というXPチックなことがやりやすいのですな。
あと、C++なんかだとよくやるけど、「使う直前で定義する」つうのも
やりやすくなるよ。定義したものの有効範囲が狭い場合は、むしろ
こっちの方が可読性が高い。
>処理系に対しても負荷が大きいような気がします
そう？
最適化しづらいつうのはあるかもしれないけど、負荷に関しては
こんなところに依存しないと思うけど……
>RubyやMatzに対して特に含むところはありません。
世の中のスクリプト言語って、大抵トップレベルがmain じゃなかったっけ？
0806689
NGNG>結局のところ、一番最初にがばって読み込んでから、
>処理を開始するのが普通のやり方だと思うけど。
Rubyも全ソースを構文木に加工してから実行するタイプだと思うけど……
0807デフォルトの名無しさん
NGNG反例として、main関数が必須なスクリプト言語を挙げておくと、pikeがあります。
モジュールやクラス毎にmain関数を定義するのはpythonやJAVAでもよくありますが、
pikeでは、main関数(というよりも、トップレベルに宣言以外のコードを書けないと言う制約)をうまく使い、
プログラム単位で拡張/再利用出来る仕組みを保証しています。
inherit "hello_world";
int main(int argc, array(string) argv) {
write("Hello world version 1.1\n");
return ::main(argc,argv);
}
上の例では、"hello_world.pike"スクリプトを拡張したprogramを作っています。
(rubyなら)requireすればいいのでは、と思われるかも知れないけど、
ここでは、クラスと同じようにprogramも拡張できるという特徴に注目して下さい。
"program"は、pikeでは、コンパイルされたpikeスクリプトを表す型で、
classやobjectと同じようなデータ型のひとつとして扱われています。
pikeでは、programを継承すると、そのprogramのトップレベルで定義した
グローバル変数はインスタンス変数に、関数はメソッドとして扱う様にする事が出来ます
。
勿論、クラスと同様にインスタンスを作成する事も可能です。
プログラム全体が class { ... } で囲まれている様な感じ、もしくは
JAVAのトップレベルの class 宣言を暗黙的に扱ってると考えるとわかりやすい。
要は、module,class,objectをまとめてハッシュ・データ構造に抽象化してる所、
スロットもjavascript等と同じように、ハッシュ要素の構文糖衣。例 obj.foo == obj["foo"]
0808807
NGNG他の言語で類似例を挙げれば、
例えば、Prothonでもモジュールとオブジェクトの差異をなくすことで、
importしたモジュールをそのままオブジェクトとして扱う事を可能にしていますね。
クラスとオブジェクトのをフラットな関係にしたように、
モジュールもオブジェクトにしてしまえば区別する必要がなくなる。
プロトタイプベースと呼んでいいものかどうかわかりませんが、
実装を考えれば自然な発想で、プロトタイプベースに通じるものがあると思います。
話をmain関数に戻します...。
main関数がある(かつ クラスとモジュールの境界がない)と、pike の様に
トップレベルに書かれたコードをclassに見立てて再利用する事が可能になります。
トップレベルに全て書いてしまうと、モジュールとして呼ばれた時にコードが実行されて
しまう為、
プログラム単位での再利用が難くなります。
もっとも、main関数がなくても自分で定義すれば済む話なので、
後はモジュール化さえしっかりしていれば、実際に困る事は殆んどありません。
多くのスクリプト言語では、プログラムがモジュールとして要求されたのか、
単体でよばれたのかを明示的にチェックする事でこの問題を回避しています。
トップレベルがmainな場合の利点は周知のようなので割愛。
main関数のある言語でのプロトタイプっぽい事例ということで、無理矢理繋げてみました。
0809デフォルトの名無しさん
NGNG> プロトタイプベースと呼んでいいものかどうかわかりませんが、
> 実装を考えれば自然な発想で、プロトタイプベースに通じるものがあると思います。
モジュールはコピれないところがちょっと厳しいけど、
オブジェクト的なエンティティの直接記述という意味では
確かにプロトタイプベース的だよな。
0810デフォルトの名無しさん
NGNG別にクラスベースとオブジェクトベースが相反する概念ってわけじゃないんじゃないか？
クラスから生成したインスタンスをプロトタイプベース並みに改変できるというわけで
クラス＝型とみなしての型付けは、やりにくいかもしれないが
0811デフォルトの名無しさん
NGNGそれクラスベースの意味がないと思う。
プロトタイプでも「設計図を渡してそれに沿ったオブジェクトを返す」ってルーチン作ればいいだけだし
0812デフォルトの名無しさん
NGNG0813デフォルトの名無しさん
NGNG> それクラスベースの意味がないと思う。
どうして？
> プロトタイプでも「設計図を渡してそれに沿ったオブジェクトを返す」ってルーチン作ればいいだけだし
つーか、それってクラスがfirst class objectなOO言語(例えばSmalltalk)そのものじゃん。
0814デフォルトの名無しさん
NGNGそれRubyの特異メソッド(クラス)
0815デフォルトの名無しさん
05/01/17 01:17:36オブジェクトがクラスに委譲せずに起動可能なメソッドを持てるかどうかに
尽きます。
0816デフォルトの名無しさん
05/01/17 02:39:520817デフォルトの名無しさん
05/01/17 19:14:280818デフォルトの名無しさん
05/01/19 20:28:30「実行前にオブジェクトの挙動が決定されるかどうか」
って線引きをしてみたんだけど合ってる？
すると、ruby なんかのスクリプト系がまたよくわかんなくなるんだけど、如何なものか
0819デフォルトの名無しさん
05/01/19 22:07:57それは「静的か動的か」の線引きでは？
0821デフォルトの名無しさん
05/01/19 23:39:3408221
05/01/20 00:19:16基準と考えておりますがどうでしょうか。
0823デフォルトの名無しさん
05/01/20 08:14:59つまり、実行機構および言語機能による分類ではなく、言語表現による分類であると。
なかなか興味深いと思います。
今まで出てきたプロトタイプベースの特性について、その分類がどのように関与するか
検討してみると面白いかもしれません。
1. 実行時メソッド変更
2. 実行時スロット拡張
3. 実行時プロトタイプ変更
0824デフォルトの名無しさん
05/01/20 14:18:23オブジェクト指向って、まだ良くわかんないんだけど
その話題はなんとなく面白そうなので、もっと展開してほすぃ。
0825デフォルトの名無しさん
05/01/21 09:37:40(A) Cloning
(B) 実行時(メソッドのinvoke時)に親から探してくる
(C) コンパイル時に親から探してくる
他には、実行効率と柔軟性の両方を考慮した、実行時にコンパイルする実装もあるけど、
要点は、Cloning or Look-up, オブジェクトが循環構造になるか階層構造をとるかって辺りにあると思う。
(B)の実装では、以下のような概念を導入してプロトタイプ的な柔軟性を実現している
・first class object, meta class
・instance specifit behavior
・dinamically lookup
それに対して、(A)の実装では、これらは設計上自然に備わっている特徴として捉える事が出来る。
0827823
05/01/22 14:25:14俺的には、クラスを記述できるかどうかはあまり本質ではないと思う。
俺は逆に、任意のオブジェクトを1つのリテラル表現として記述できるかどうかが
インスタンスベース言語であるかどうかを判断する表現上の基準になるんじゃないかと
思うのだが。
0828デフォルトの名無しさん
05/01/22 19:52:57http://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html
このへんを読むと、プロトタイプベースの言語では、あるインスタンスの
スロットを探してメソッドがなかったら、その親のスロットを捜しに行くように
読めます(これがプロトタイプチェーン?)。
素人目には、こんなことをしなくても、clone()の時点でスロット全部コピー
すればよさそうに思えるのですが、この動作の利点は何なんでしょうか?
a)スロットのメモリ領域を節約できる(微々たるもんだよなー)
b)親のメソッドを差し替えたり、親にメソッドを追加したとき、
子からも新しいのを使うことができる。
程度しか思いつきません。
b)は、正直、「こんなことやっちゃっていいの?」と思います。
対話的なプログラミングなら嬉しいかもしれないけれど。
0829デフォルトの名無しさん
05/01/22 19:58:480830818
05/01/22 20:01:41え～!?
「newobj = obj.Clone();」とかやっても、インスタンスを記述したことにならないやん
インスタンスは変数の裏に隠れて移動するだけだし
リテラルとして考えると、「1」とか「"text"」とかは確かに記述できるけど、
それはクラスベースでもプロトタイプベースでも、あまり変わらないし
任意のオブジェクトを記述できる手段として“クラス”があると捕らえているのよ
それを 1st class object と捕らえるとか、そういう話云々は別として
0831828
05/01/22 20:50:26まあそうなんでしょうねえ。
読み返していたら、>>58を見付けました。
> 画面にたくさんのテキストフィールドがあって、
>それのイベントハンドラをいっせいに切り替えるようなこと。
>画面のモードによって、いっせいにフィールドの挙動を変えるようなこと。
たとえば画面上のボタンを押した時点でこういう挙動を起こしたければ、
「スロットまるごとコピー方式」だけじゃうまくいきませんね。
0832デフォルトの名無しさん
05/01/22 22:44:26基本的に分かっちゃないくせにぶっちゃう莫迦だなコイツ。放置の方向か？
0833818
05/01/22 23:03:49ああ、俺が馬鹿なのは否定できないし、スルーしても別にかまわないし、
そういえば 827 と 830 は微妙に話が噛み合ってないと今更突っ込みたくもなったけど、
基本的に、リテラルを除けば
「記述できるインスタンス」と「記述できないクラス」は存在しないとは思っている
0834デフォルトの名無しさん
05/01/22 23:10:33IOのcloneはスロット全部コピーするらしいよ。
効率を考えると全部コピーした方がいいけど、b)の柔軟性も
魅力的。
個人的にはcloneは全コピーで、それとは別にdelegateが
あったほうがいいなあ。
0835828
05/01/22 23:24:44>IOのcloneはスロット全部コピーするらしいよ。
え、そうなの?
俺、↓読んで、てっきり逆だと思ってました。
http://sumim.no-ip.com:8080/wiki/493
| 実手続きとしてチャイルドを作るときに clone（あるいは clone() ）を
| 使用できるものと、clone は copy（shallow copy）と同義で、
| 単にプロトタイプの複製を作るだけのものがありまぎらわしい。
| 実は Io を除き、ほとんどの言語は後者で、むしろこのほうが一般的。
| つまり、我々が一般にイメージするクローン（じつはチャイルド）を
| clone で作ることはできない。
0836デフォルトの名無しさん
05/01/22 23:27:44shallow copy って事は、スロットを複製しない浅いコピーって解釈で良いんじゃない？
Io は前者、つまり clone でスロットも複製するって感じで
0837デフォルトの名無しさん
05/01/23 00:46:440838デフォルトの名無しさん
05/01/23 00:56:56>>829とか>>832とか>>837とか、具体的なことを何も言わずに、1行かそこらのレスで
何か偉そうなことを言った気になれる奴ってのは楽でいいね。
ｵﾚﾓﾅｰ
0839デフォルトの名無しさん
05/01/23 01:27:54全部コピーはしてないよ。
proto スロットにプロトタイプとなるオブジェクトが入れられて、
スロットが見付からない際に利用される。
hoge := Object clone
piyo := hoge clone
hoge greet := method("hello" print)
piyo greet # "hello"
hoge greet = method("hoge!!" print)
# ↑コピーするなら、これは効かないはず
piyo greet # "hoge!!"
# piyo の持つスロットは proto 唯一つ。
0840デフォルトの名無しさん
05/01/23 05:01:29スロットをコピーするといっても、実態を全部コピーするわけではなく、
その参照をコピーするだけに留めるとクローン生成時のコストは抑えられる。
スロット追加時に、その参照から実態を複製しそこに新しいスロット追加する。
0841823
05/01/23 07:34:46> 「newobj = obj.Clone();」とかやっても、インスタンスを記述したことにならないやん
・・・
そういうのを排除するためにわざわざ「リテラルで」という限定詞を入れたんだけど。
> リテラルとして考えると、「1」とか「"text"」とかは確かに記述できるけど、
> それはクラスベースでもプロトタイプベースでも、あまり変わらないし
例えば、
cat = object {
mew(times) { self.make_sound("mew") }
walk(direction, distance) { self.dir = direction. self.move(distance) }
...
}
みたいな話ができてやっと「インスタンスベース」と言えるんじゃないか、って話な。
0842デフォルトの名無しさん
05/01/23 07:44:00javascriptならそれでできるぞ
0844デフォルトの名無しさん
05/01/23 09:56:09str = "string"
0845デフォルトの名無しさん
05/01/23 10:11:28文字列以外のオブジェクトは?
0846823
05/01/23 10:20:27> str = "string"
そういうのを排除するために「任意のオブジェクトを」1つのリテラル表現として
記述できるかどうか、と書いたのだが。
0847デフォルトの名無しさん
05/01/23 10:47:50こういうのもリテラルと呼ぶのか
cat = object(
mew(times) { self.make_sound("mew") },
walk(direction, distance) { self.dir = direction. self.move(distance) },
...
);
0848デフォルトの名無しさん
05/01/23 10:52:58ちゃう、ちゃう。ここで“前者”はディープコピーではなくて、チャイルド（プロトチェーンに
委譲する、俗に“クローン”と呼ばれているもの）を作ること。Io は clone でチャイルド
を作るけど、SELF などは clone でチャイルドを作らずにシャローコピーを作るってこと。
0849デフォルトの名無しさん
05/01/23 10:57:38>>815じゃ駄目なの？ これに尽きると思うけど。
0850デフォルトの名無しさん
05/01/23 11:15:20メソッドも自己完結してる
0851デフォルトの名無しさん
05/01/23 11:25:42ぜんぶstaticやん。Mathはネームスペースを提供しているだけだがな。
0852823
05/01/23 12:14:39>>815はメッセージ送信の実行機構による分類でしょ。
もちろんそれはそれで1つの正しい分類だしそれに異存はない。
が、今は言語表現による分類をするとしたら、という話をしているわけ。
0854デフォルトの名無しさん
05/01/23 12:30:45字面を見る限り、Javaの無名クラスとどう違うのかって気が…
0855823
05/01/23 16:47:52> 字面を見る限り、Javaの無名クラスとどう違うのかって気が…
だからさ、そこがポイントなわけよ。
Javaの無名クラスはあくまでクラスでしょ。
それをインスタンスに対してできてこそのインスタンスベースじゃない？
0856デフォルトの名無しさん
05/01/23 17:09:42んー、それはJavaがクラスベースな言語なんだから当然の話であって、
こういう書き方ができるかどうかって事と、
クラスベースかインタスタンスベースかって事は直交した問題なんじゃ?
0857818
05/01/23 19:08:46＞例えば、
＞cat = object {
＞mew(times) { self.make_sound("mew") }
＞walk(direction, distance) { self.dir = direction. self.move(distance) }
＞...
＞}
＞みたいな話ができてやっと「インスタンスベース」と言えるんじゃないか、って話な。
実は、やっとココで >>818 の話に繋がるんです
仮に cat に代入されるオブジェクトが『実行時、今まさに作られるのならば』インスタンスベース
しかし、オブジェクトを生成する為の“メタオブジェクト”と呼べるものが『既に作られていたのならば』クラスベース
では無いかと思ったわけで
0858デフォルトの名無しさん
05/01/23 19:09:170859823
05/01/23 19:12:17> >Javaの無名クラスはあくまでクラスでしょ。
>
> んー、それはJavaがクラスベースな言語なんだから当然の話であって、
でしょ。
だったら、インスタンスベース言語ならそういう表現ができて当然なんじゃない？
0860デフォルトの名無しさん
05/01/23 19:14:31少なくとも Io でそういう表現は出来なかったと思う
0861823
05/01/23 19:15:42> 実は、やっとココで >>818 の話に繋がるんです
> 仮に cat に代入されるオブジェクトが『実行時、今まさに作られるのならば』インスタンスベース
実行時に生成されるかコンパイル時に定数として生成されるかで振舞いが変わるかな？
いずれにせよ、そのオブジェクトの動作はリテラルとして記述された通りなわけで。
0862823
05/01/23 19:17:03> 少なくとも Io でそういう表現は出来なかったと思う
まあそういう例もあるだろうね。
その場合はプロトタイプを使ってオブジェクトを生成するしかないから、
インスタンスベースとプロトタイプベースを区別したほうがいいのかも。
0863818
05/01/23 19:23:05＞実行時に生成されるかコンパイル時に定数として生成されるかで振舞いが変わるかな？
あ、↑みたいに言った方が良かったかも ^-^;
件のコードは、
「object まで到達した時点でオブジェクトが作成され、次いで mew と walk が接続され、そして cat に代入される」
……なら、実行時に作ったということでインスタンスベース
「object まで到達した時点で、既に完成されたオブジェクトが生成され cat に代入される」
……なら、クラスベース
ということで
0864デフォルトの名無しさん
05/01/23 19:36:40おいおい。自説大事に生粋のインスタンスベースを例外扱いかよ。
真性だな。
0865デフォルトの名無しさん
05/01/23 19:40:28プロトタイプベースとインスタンスベースとオブジェクトベースは
同じものの別の呼び名です。念のため。
0866818
05/01/23 19:44:09『プロトタイプベース』『クラスベース』『オブジェクト指向』がそれぞれ違う概念として紹介されて棚w
クラスが無ければプロトタイプベース、
継承しなければクラスベース、
継承してればオブジェクト指向
ってな感じに。俺は違和感あった
0867デフォルトの名無しさん
05/01/23 19:49:30シンタックスの妙でインスタンスベースっぽさを名乗るのは勝手だが。
インスタンス特異と見せかけて特異クラスを使うRubyの特異メソッドもしかり。
0868デフォルトの名無しさん
05/01/23 20:03:36んじゃこれどう見る？
class Hoge begin
proc void Fuga begin
～
end;
end;
これがインスタンスベースだって言ったら怒る？
この場合はルートのオブジェクトに対して class メッセージを送ってみたんだが
すると、Hoge という名のクラス （1st class object） が生成される、という仕組み
0869デフォルトの名無しさん
05/01/23 20:05:32まあとにかく、経験則のみで既存概念の再定義をやたら試みようとするのが
オブジェクト指向界隈の悪しき慣習だから、オリジナルペーパーや出典を明らか
にしない解説の類は眉唾で読まないとね。自分が紹介したり解説している考え方
の出所すらしらずに文章を書いて（カネまでもらってｗ）いるヤツのなんと多いことか。
0870デフォルトの名無しさん
05/01/23 20:10:44>自分が紹介したり解説している考え方の出所すらしらずに
>文章を書いて（カネまでもらってｗ）いるヤツのなんと多いことか。
だって、全部自分の「再発明」なんだもん・・・
0871デフォルトの名無しさん
05/01/23 20:15:25classメソッドはどこに定義されているの？
0872デフォルトの名無しさん
05/01/23 20:18:52ルートオブジェクト
ちなみに、ルートオブジェクトはこの言語の世界が生まれたときには既に存在していました
つまり神に相当するオブジェクトです
……ま、でっちあげの脳内言語だけどな
0873868
05/01/23 20:22:14この当たりはよく分からん
0874デフォルトの名無しさん
05/01/23 20:26:53じゃあインスタンスベースでいいけど、脳内じゃな… ｗ
そもそもHogeとかFugaとか関係ないし。わけわかめ。
0875デフォルトの名無しさん
05/01/23 20:45:18うん。脳内。
だけど、基盤は出来てるから class メソッドをちゃんと組み込めばいいだけ。
面倒だからやりたくないけど。
0876デフォルトの名無しさん
05/01/23 21:46:04お気軽なのがプロトタイプベース
適当なのがインスタンスベース
0877デフォルトの名無しさん
05/01/23 21:49:590878デフォルトの名無しさん
05/01/23 22:16:50>> んー、それはJavaがクラスベースな言語なんだから当然の話であって、
>でしょ。
>だったら、インスタンスベース言語ならそういう表現ができて当然なんじゃない？
「でしょ」じゃなくってさあ。
クラスベースの言語でも、無名クラスのような表現ができるのとできないのとがあるように、
インスタンスベースの言語でも、こういう表現ができるのとできないのがあっていい。
だから、この表記ができるかどうかの問題と、その言語がインスタンスベースであるか
どうかの問題は、直交している、って言ってるの。
0879デフォルトの名無しさん
05/01/23 22:19:10『直交』という表現よりも『ニアミス』というか『次元がズレている』っていう表現の方がよくないか？
まぁ、書き方は幾らでも考え付くんだ
そのなかで『プロトタイプベースって一体何？』って話だよな？
0880デフォルトの名無しさん
05/01/23 23:33:57だから対立した考え方じゃないんだってば。クラスベースで、インスタンスが自前の
メソッドや属性を自由にできない…という制約をといたのが、インスタンスベースだ。
0881デフォルトの名無しさん
05/01/23 23:41:50くどいようですが、インススタンスベースとプロトタイプベースは同じものです。
プロトタイプベースというと、プロトタイプの複製でオブジェクトを生じさせること
やプロトタイプチェーンによる委譲といった、特徴だけど、本質ではないところ
のみ取りあげて、やたらクラスベースと対比させたがる人が多いので困ります。
0882デフォルトの名無しさん
05/01/23 23:45:35『複製でオブジェクトを生じさせる』 を 『クラスに因らないオブジェクト生成』 だと解釈すれば本質だと思うけど
0883デフォルトの名無しさん
05/01/24 00:04:490884デフォルトの名無しさん
05/01/24 00:36:32いや。それが本質じゃないだってば…。orz
0885デフォルトの名無しさん
05/01/24 00:44:58プロトタイプの語感からくる間違った認識で議論されるのは困ると思う。
だからインスタンスベースかオブジェクトベースと呼ぼう！
A Theory of Object でもオブジェクトベースって言っているしね。
http://tinyurl.com/3tnke
0886823
05/01/24 12:07:41> 「object まで到達した時点で、既に完成されたオブジェクトが生成され cat に代入される」
> ……なら、クラスベース
クラスは存在せず、プロトタイプからコピーする場合でも、クラスベースと呼ぶ？
0887823
05/01/24 12:09:08はい。それ承知の上で、あえて区別分類してみようかと。
というのも、インスタンスベースだからといってプロトタイプという概念が
必然かどうかはまだ議論の余地があると思っています。
0888823
05/01/24 12:12:16> これがインスタンスベースだって言ったら怒る？
> この場合はルートのオブジェクトに対して class メッセージを送ってみたんだが
> すると、Hoge という名のクラス （1st class object） が生成される、という仕組み
クラスが存在する時点でクラスベースとおもわれ・・・
というか、それがインスタンスベースだと言うのならSmalltalkはインスタンスベース？
0889823
05/01/24 12:14:10> クラスベースの言語でも、無名クラスのような表現ができるのとできないのとがあるように、
> インスタンスベースの言語でも、こういう表現ができるのとできないのがあっていい。
もちろん、一般的な定義としてのインスタンスベースならば、その通り。
今議論しているのは、言語表現としてインスタンスベースあるいは
プロトタイプベースを定義するのならば、どういう基準になるのだろうか
という話。
0890823
05/01/24 12:15:31じゃ、rubyはインスタンスベース？
Smalltalkにもいくつかインスタンス毎にメソッド定義できる環境があったけど、
そういうのもインスタンスベース？
0891デフォルトの名無しさん
05/01/24 12:26:13Rubyの特異メソッドはインスタンスに定義しているようにみせて、
実は特異クラスという見えない無名クラスに定義しています。
したがって、セマンティックス的にはクラスベースです。
シンタックス的にはインスタンスベースっぽいと言っても構わないでしょう。
Smalltalkの例もしかりです。とにかく、実質クラスにメソッドを定義
しなければならなければクラスベースです。
0892デフォルトの名無しさん
05/01/24 12:49:090893デフォルトの名無しさん
05/01/24 13:01:00RubyもSmalltalkもクラスはまた別のクラスのインスタンスです。
Rubyは特異メソッドでクラスメソッドを“持っている”ように見えますが
これも特異クラスの暗黙の介在が必要です。したがって、こうしたクラスも
それ自体が自身で起動できるメソッドを持てているわけではないのです。
0894823
05/01/24 13:25:32> Smalltalkの例もしかりです。とにかく、実質クラスにメソッドを定義
> しなければならなければクラスベースです。
いや、Smalltalkの例の場合には、インスタンスにスクリプトをつけられる環境で、
それは無名クラスではなく、インスタンスがスクリプトのメソッド辞書を持っていた。
また、pythonの場合には特異クラスではなく、これまたオブジェクトのスロットに
直接バインドできる。
rubyはよく知らん。
0895デフォルトの名無しさん
05/01/24 15:34:14インスタンスにメソッドをバインドできても、それを起動するための
しくみをクラスに仕込まなければならないならば、結局は同じことです。
繰り返しになりますが、そうした機構をもってインスタンスベース的と
宣伝するぶんには差し支えないと思います。
Pythonにはインスタンスベースの素養が十分あると言って良いと思います。
0896823
05/01/24 15:47:59> インスタンスにメソッドをバインドできても、それを起動するための
> しくみをクラスに仕込まなければならないならば、結局は同じことです。
いや、スクリプトを書く側にとっては、クラスに一切の変更を加えることなく
新しいメソッドを追加できた。
0897デフォルトの名無しさん
05/01/24 16:39:29ですから、くどいようだけどそれはRubyの特異メソッドと同じこと。
ユーザーは特異メソッドを使うにあたって特異クラスを意識する
必要は必ずしもないわけだから。ユーザーがクラスの介在を意識しないで
済んでしまうような計らいがあるとき、それはインスタンスベースだと
言い切るのなら、それはそれで構わないと思う。ただ、無用な議論を避ける
ために、但し書きは必要でしょうけど。
「自分はシンタックスにおいてインスタンスベースなら、それの言語・
処理系はインスタンスベースだと解釈する立場だ」…とかね。
0898823
05/01/24 16:45:36> 「自分はシンタックスにおいてインスタンスベースなら、それの言語・
> 処理系はインスタンスベースだと解釈する立場だ」…とかね。
いや、俺の立場がどうこうという問題じゃなくて、
今議論しているのは言語表現上(syntaxだけではなく、constructsの問題)で
クラスベースとインスタンスベース(あるいはプロトタイプベース)を区別する
基準はできないだろうか、という話なんだが。
できれば>>822あたりからの流れを読んでもらえると助かる。
0899デフォルトの名無しさん
05/01/24 17:26:08クラスを用いてオブジェクト生成に重みを置くなら「クラスベース」
クラスを用いないオブジェクト生成に重みを置くなら「インスタンスベース」
で良いんじゃない？
クラスからのオブジェクト生成後の変更可能性は生成になんら関わらないし、
インスタンスベースが“クラス”オブジェクトを持っていてはいけないという規定も無いし。
自称･他称が違うこともあるだろうが仕様が無い。
0900デフォルトの名無しさん
05/01/24 20:18:54「プロトタイプベース」?
プロトタイプへの参照を持たず、いっそcloneもできないインスタンスベースの
言語って考えられないわけじゃないよね。現実にあるかどうかは知らんけど。
0901デフォルトの名無しさん
05/01/24 21:46:36インスタンスベースやプロトタイプベースでクラス指向する、
って言い方もできるわけだよな。
構文糖衣の差や、クラスの探索等を組み込みでやるか、
自力でやるか程度の違い。
どこで線引きするかなんて個人の解釈でしかない。
この議論は無意味だ。
09021
05/01/24 22:07:56あなたにとって無意味かもしれないけど少なくとも私にとっては無意味じゃありませんね。
「プロトタイプベース」「インスタンスベース」についてはこのスレを見てもわかるように
言葉の定義がまだはっきりしていません。
（誰かが定義したしないという話ではなく広く一般に知れ渡った定義がはっきりしていないということ）
それを手探りで徐々に輪郭を作っていく議論は有益だと思いますよ。
ちょっと発散気味かもしれませんけど。
0903デフォルトの名無しさん
05/01/24 22:36:010904デフォルトの名無しさん
05/01/24 22:38:50いや、901が言いたいのは、823が言う言語表現なんてどうとでもなる
から、そこでの線引きについて議論することは無意味だってことだろ？
09051
05/01/24 22:51:04815 「クラスの有無」
オブジェクトがクラスに委譲せずに起動可能なメソッドを持てるかどうか
メッセージ送信の実行機構による分類(852)
クラスベースで、インスタンスが自前の
メソッドや属性を自由にできない…という制約をといたのが、インスタンスベース(880)
とにかく、実質クラスにメソッドを定義しなければならなければクラスベース(891)
クラスもそれ自体が自身で起動できるメソッドを持てているわけではないのです(892)
インスタンスにメソッドをバインドできても、それを起動するための
しくみをクラスに仕込まなければならないならば、結局は同じことです(895)
クラスが存在する時点でクラスベースとおもわれ(888)
818 「実行時にオブジェクトが定義されるか」
実行前にオブジェクトの挙動が決定されるかどうか
クラスをコードとして記述できるかどうかの意味(820)
「記述できるインスタンス」と「記述できないクラス」は存在しない(833)
『実行時、今まさに作られるのならば』インスタンスベース
オブジェクトを生成する為の“メタオブジェクト”と呼べるものが
『既に作られていたのならば』クラスベース (857)
09062
05/01/24 22:51:34ソース上のプリミティブな要素がクラスなのかインスタンスなのか
実行機構および言語機能による分類ではなく、言語表現による分類(823)
827 「オブジェクトのリテラル表記の可否」
任意のオブジェクトを1つのリテラル表現として記述できるかどうか
言語表現による分類(852)
Javaの無名クラスはあくまでクラス
それをインスタンスに対してできてこそのインスタンスベース(856)
実行時に生成されるかコンパイル時に定数として生成されるかで振舞いが変わるかな？(861)
無名だろうとクラスにメソッドを定義しないといけないのならクラスベース(867)
ユーザーがクラスの介在を意識しないで済んでしまうような計らいがあるとき、
それはインスタンスベースだと言い切るのなら、それはそれで構わないと思う。
ただ、無用な議論を避ける ために、但し書きは必要(897)
899 「直交するものではないので重みづけで判断」
クラスを用いてオブジェクト生成に重みを置くなら「クラスベース」
クラスを用いないオブジェクト生成に重みを置くなら「インスタンスベース」
クラスからのオブジェクト生成後の変更可能性は生成になんら関わらないし、
インスタンスベースが“クラス”オブジェクトを持っていてはいけないという規定も無いし。
09073
05/01/24 22:52:11インスタンスベースとプロトタイプベースを区別したほうがいいのかも
インスタンスベースだからといってプロトタイプという概念が必然かどうか(887)
インスタンスベースのうち、プロトタイプチェーンを持っているのが 「プロトタイプベース」？(900)
865 「インスタンスベース＝プロトタイプベース」
プロトタイプベースとインスタンスベースとオブジェクトベースは同じものの別の呼び名です
自説大事に生粋のインスタンスベースを例外扱いかよ。 (864)
クラスベースの言語でも、無名クラスのような表現ができるのとできないのとがあるように、
インスタンスベースの言語でも、こういう表現ができるのとできないのがあっていい。 (878)
プロトタイプベースというと、プロトタイプの複製でオブジェクトを生じさせること
やプロトタイプチェーンによる委譲といった、特徴だけど、本質ではないところ
のみ取りあげて、やたらクラスベースと対比させたがる人が多いので困ります。 (881)
885(865派生) 「プロトタイプベースと呼ぶのはやめよう」
プロトタイプの語感からくる間違った認識で議論されるのは困ると思う。
だからインスタンスベースかオブジェクトベースと呼ぼう！
0908デフォルトの名無しさん
05/01/24 22:53:48えーと。そのプロトタイプベースの言語を最初に作った当人が、クラスベースのアンチを
意識して、本質じゃないところを強調しちゃったもんだから、ややこしいことになっている
わけ。で、あとで客観的に分析して本質を突いてくれた本もあるんだけど、これが洋書で
高いから、誰も読んでないとくる。当然、インスタンスベースとかオブジェクトベースっても
通じやしないし、再三プロトタイプベースの別の呼び名だと言っているそばから、俺定義
をはじめるバカもいるってな始末でどーしようもない状態なのよ。
0909デフォルトの名無しさん
05/01/24 23:00:4809101
05/01/24 23:11:24まぁそれもそうだけど、ここに書き込んでいる人は私含めて権威ある定義を知らないので
話が噛み合わなかったりしてはっきりさせたいってのがあるのではないかと。
>>908
その本読んでいるのだったら何が本質と書かれていたか教えて欲しいです。
>>904
901の「この議論」が指しているものが何かレスからは厳密に読み取れないのでなんとも･･･
823定義が独走しちゃっている感は確かにありますけどね。
09111
05/01/24 23:16:03・プロトタイプベース
・インスタンスベース
・オブジェクトベース
0912デフォルトの名無しさん
05/01/25 00:55:19だけは、言葉に対するセンスが無いと思う。
0913デフォルトの名無しさん
05/01/25 01:34:30なぜ？
プロトタイプベースは限定的なイメージを持たせがちだし、
オブジェクトベースはオブジェクト指向と混同しがち。
インスタンスベースなら、クラスとの背反という間違った発想を払拭してくれる
語感と併せて、よい落としどころだ思うけど。
けれど、プロトタイプベースで探してくる人が多いと思うから、今と同じ
プロトタイプベース・オブジェクト指向 2でいいんでないの？ >>1に但し書き入れて。
0914デフォルトの名無しさん
05/01/25 01:45:190915デフォルトの名無しさん
05/01/25 01:46:01instanceって言葉のの意味解ってる？
0916言っとくけど823じゃないよ
05/01/25 05:18:08> 当然、インスタンスベースとかオブジェクトベースっても
> 通じやしないし、
このスレじゃ十分以上に通じてるじゃん(藁
> 再三プロトタイプベースの別の呼び名だと言っているそばから、俺定義
> をはじめるバカもいるってな始末でどーしようもない状態なのよ。
そいつ、再三にわたって「本来の定義は置いておいて、言語表現上のconstructs
から分類するとしたらどういう分類がありうるか、という議論をしている」と
いうようなことを言ってなかったか？
その議論に割り込んで「別の呼び名だ、馬鹿」と、マトハズレな痴態を晒す
マヌケもいるって始末でどーしようもない状態になったわけ。
しかも、constructsをsyntax sugarで覆えるわけないのにsyntax sugarだとか
言ってる大馬鹿もいるしでもう爆笑するしかないね。
0917デフォルトの名無しさん
05/01/25 10:40:43「インスタンスベース」への受け入れ方で、その理解度がはっきりと
分かるというのはなかなかおもしろい効能だ。
0918デフォルトの名無しさん
05/01/25 11:34:59その高い本の書籍名とISBN番号希望！
昔は洋書読まなかったんだけどAmazonができてから良く読む用になったんよ、
良い本あれば元値にはこだわらないから教えてほしい。
（昔は入手が大変だったのと$1 = \130の頃でも２００円換算とかされてとても買う気になれんかった）
0919デフォルトの名無しさん
05/01/25 12:14:18定義もおぼつかない状態で言語表現上の構造概念を論じること
は可能なの？
0920デフォルトの名無しさん
05/01/25 13:40:28> 定義もおぼつかない状態で言語表現上の構造概念を論じること
> は可能なの？
言語表現上の構造や概念から定義しようという議論であることがまだ理解できない？
0921デフォルトの名無しさん
05/01/25 15:48:430387947752
0922デフォルトの名無しさん
05/01/25 17:54:48ありがとん。
0923デフォルトの名無しさん
05/01/25 18:28:44プロトタイプ言語のクラスレスなオブジェクトはinstance っていう言葉の持つ自然な意味と
全く合致していない（むしろ対立している）から「インスタンスベース」っていう言葉はまずいでしょ。
英語としての言葉の意味なんてどうでもいいっていうなら、メソッドベースでもフレームベースでも
moon base でも何でもいいじゃん。
0924デフォルトの名無しさん
05/01/25 19:25:03moon base は如何なものか。
せめて white b(ry
0925デフォルトの名無しさん
05/01/25 20:06:44謎のの方か？、アルファの方か？、これで年齢が一回りは異なる訳であるが。
0926デフォルトの名無しさん
05/01/25 21:10:27そんなことにこだわっていると、かえって本質の理解を妨げるよ。
0927デフォルトの名無しさん
05/01/25 22:08:55「電話番号張り付け検出スクリプト」にひっかかって警察に通報されてそうだ。
0928デフォルトの名無しさん
05/01/25 22:17:33http://www2.alc.co.jp/ejr/index.php?word_in=instance&word_in2=%82%A0%82%A2%82%A4%82%A6%82%A8&word_in3=PVawEWi72JXCKoa0Je
| instance
| 【名-1】 場合｛ばあい｝、事実｛じじつ｝、（事実｛じじつ｝を例証
| ｛れいしょう｝するための）例、事例｛じれい｝
これだけではよくわからんが、
| * instance a case of
| ～の一例｛いちれい｝を挙げる
ってのがあるから、
「(クラスのような)テンプレートに相当するようなものがあり、
その中のひとつの例、実体」
ってニュアンスなのかな。だとすると「インスタンスベース」はまずいね。
「オブジェクトベース」では、いまや「普通」の(クラスベースの)OO言語を
指してしまいそうだし、
「プロトタイプベース」では、もしプロトタイプチェーンを持たないような
言語があったら困る。
さあ困った。
0929デフォルトの名無しさん
05/01/25 22:22:40AmazonのURLはISBN番号を含んでいる事をたった今知りました。
A Theory of Objects (Monographs in Computer Science)
http://www.amazon.co.jp/exec/obidos/ASIN/0387947752/
0930デフォルトの名無しさん
05/01/26 00:03:480931デフォルトの名無しさん
05/01/26 00:16:53Gemsの原書もそんなものだし、普通じゃないかな？
0932デフォルトの名無しさん
05/01/26 00:24:020933デフォルトの名無しさん
05/01/26 00:26:38そんだけだったら俺も手はださんだろうけど、専門書だったら普通じゃないか？
俺は技術書系の活字中毒だからなぁ、このくらいの値段の本だと年に１０冊じゃ効かないかも。
＃金がないときゃ図書館にお願いするが。
0934デフォルトの名無しさん
05/01/26 22:53:50この書込にはおそらく電話番号書込自動警察通報システムが働いた
0935デフォルトの名無しさん
05/01/26 23:00:22でも03でこの長さは電話番号じゃないからなぁ。
0936デフォルトの名無しさん
05/01/27 11:27:2603-8xxx はないよね。3xxx と 5xxx だけ？
0937デフォルトの名無しさん
05/01/28 13:55:03よく分かっていないものに対する
たぶん、こんなもんだろうという
言語表現上の定義、まだぁ？
0938デフォルトの名無しさん
05/01/29 11:35:28SHADOだろ（ｗ
0939デフォルトの名無しさん
05/01/29 13:10:49制作はどっちもITCなんだがなぁ、１０年以上の開きがあるんだよなぁ。
コーニッグ司令官とストレイカー長官じゃ。
0940デフォルトの名無しさん
05/01/29 14:54:02＝＝＝＝＝＝＝＝ 終 了 ＝＝＝＝＝＝＝＝＝
0941デフォルトの名無しさん
05/02/03 20:37:550942Javaのスイッチ文のように作用し、
05/02/03 20:55:500943デフォルトの名無しさん
05/02/07 19:49:57単純にテーブル生成するとメモリ食ってヒドイ目に遭うんです。
0944デフォルトの名無しさん
05/02/11 01:27:14Methodの呼び出し部分をJIT化して効率よくなるってことは、
呼び出されるMethodの方は、当然JITコンパイルされてるんだよね?
0945デフォルトの名無しさん
05/02/11 02:24:20CPUの分岐予測みたいに以前のメソッド呼び出しだけを保存しておいて、
次回の関連オブジェクトの状態も不変なら＜抽象的でごめん
そのままコール、だめならもっと上位の定義から辿る。
以上素人考え……遅そう。
>>944
たぶんCPUのキャッシュ効率を考えてるんじゃないかな。
0946デフォルトの名無しさん
05/02/18 23:32:39Effective JavaScript（ttp://www.interq.or.jp/student/exeal/dss/ejs/）
JavaScript 深層（ttp://www.hawk.34sp.com/stdpls/jsnotes/jssinso/）
結構当てになると思うけどどうよ？
0947デフォルトの名無しさん
05/02/19 00:43:200948デフォルトの名無しさん
05/02/20 18:31:110949デフォルトの名無しさん
05/02/20 18:32:35殺してやる
0950デフォルトの名無しさん
05/02/20 18:33:38殺して姦る
0951デフォルトの名無しさん
05/02/20 21:12:37>>948
どの辺が？
0952デフォルトの名無しさん
05/02/22 23:39:31機能を盛り込もうとしています。
言語そのものは、C風の文法の形無し言語です。
んで、
o = new_object();
とすることで、o.hoge 形式で参照可能な連想配列が取得できるようにする。
そうすれば、後はクロージャを実装するだけで、
new_point(x, y) {
o = new_object();
o.x = x;
o.y = y;
o.move = function (x, y) {
o.x += x;
o.y += y;
}
}
なんて形で、そこそこそれっぽいものが書けそうな気がするんですが、
どんなもんでしょうか。
そんなのOOじゃねえ、とか、それじゃ実装できんだろ、とか、
気が付くところがあったら教えてくださいませ。
# プロトタイプチェーンはもちょっと後で考えるつもり。
0953デフォルトの名無しさん
05/02/23 08:32:120954デフォルトの名無しさん
05/02/23 09:11:38普通に{...}があるかないかじゃダメなのか？
0955デフォルトの名無しさん
05/02/23 11:49:56functionって関数名じゃなくて関数宣言の予約語じゃないの？
0956デフォルトの名無しさん
05/02/23 14:21:330957952
05/02/24 00:23:25反応ありがとう。
>>955が正解で、functionは予約語です。
んで、>>952ではいくつかポカしてて、通常の関数定義の際もfunctionは
必要で、かつ、new_point()はただの関数なので、>>952のリストは実際にはこうなります。
function new_point(x, y) {
o = new_object();
o.x = x;
o.y = y;
o.move = function (x, y) {
o.x += x;
o.y += y;
}
return o; ←returnが必要
}
関数のネストは今のところ考えてないので、スコープは、
・グローバル
・関数内ローカル
・ネストした分のクロージャ
になるんじゃないかと思ってます。
0958デフォルトの名無しさん
05/02/24 10:45:47みたいな議論、どーでもいい話で盛り上がってるっぽくてﾜﾗﾀ
そんなん、プロトタイプとなるインスタンスへの委譲がなくとも、
インスタンスをプロトタイプとして新しいインスタンスを作るんだから、プロトタイプ～でええやん。
こーゆーつまらん議論を喧喧ｶﾞｸｶﾞｸやって、しまいには辞書まで引っ張り出してくるのって、
きっと（ｒｙ
0959デフォルトの名無しさん
05/02/24 10:55:240960デフォルトの名無しさん
05/02/24 22:08:44そーゆーつまらん議論はとっくに終わっているのに、わざわざほじくりだして
しかもageるのって、きっと(ry
0961デフォルトの名無しさん
05/02/27 12:58:241000目前でこれは悲しいので、一応ageとく。
次スレはいらないの?
0962デフォルトの名無しさん
05/02/27 15:26:12ノ
0963デフォルトの名無しさん
05/02/27 15:29:240964デフォルトの名無しさん
05/02/27 21:56:440965デフォルトの名無しさん
05/02/27 22:52:20頭が痛くなるだけで
何も生み出さない
次スレは*無し*の方向で
0966デフォルトの名無しさん
05/02/28 00:24:42あんたの頭が足りないのをスレのせいにされてもなあ…
上のほうには有意義な議論もあったろうに。
0967デフォルトの名無しさん
05/02/28 01:09:09結局ここに書き込んでる奴は、何がしたいわけ？
>>3-4みたいなマイナー言語並べて各自の勝手な解釈で
分類の仕方に終始してるだけというか。
何が有意義なのかねえ・・
言語ごとに専用スレ立てれば？
0968デフォルトの名無しさん
05/02/28 02:02:03HSPスレなりマ板なりどこでも逝けばいいだろうに。
0969デフォルトの名無しさん
05/02/28 02:49:29合う合わないの話なんてしてないのに。
自分が低脳だとは考えたことが無いんだろうね。
痛すぎるよ、君。
0970デフォルトの名無しさん
05/02/28 08:39:01すげえ。本物の低脳だ。
0971デフォルトの名無しさん
05/02/28 19:33:030972デフォルトの名無しさん
05/02/28 19:43:12すげえ。本物の低脳だ。
0973デフォルトの名無しさん
05/03/01 01:31:10>>964
「インスタンスベース」という言葉は一般に使われていない上に、
英語としても変(>>928)だから、却下されるべきだと思うよ。
俺としちゃ、プロトタイプOOな言語が具体的にどういう時に役に立つのか、
もうちょっと色々話を聞きたいと思ってる。
>>133のリンク先にある話は割とわかるんだが、200～あたりで話されている、
「プロトタイピングで便利」というのは納得しかねるなあ。動かしながらいじるのが
便利だとして、具体的にどこをどういじりたいんだろう?
0974デフォルトの名無しさん
05/03/01 04:04:250975デフォルトの名無しさん
05/03/01 10:11:19“だとすると「インスタンスベース」はまずいね”と仰ってしまう >>928 は
果たして参考になるのだろうか…？
0976デフォルトの名無しさん
05/03/01 10:54:04意味をよく掴めなかったので、つっこみつつ質問。
> 自ら“英語に疎い”と認めつつ、実際に動詞としての使用例で以って
疎い思っているからこそ(失礼、>>928さん)、辞書をひいたのでしょう。
確固とした情報源を使うことで、(変な論理で話を変な方向に展開させなければ)
信頼できる情報となり得るのではないでしょうか。
まさか、「英語に疎い人が辞書を使っても、信頼なんかできないよ」
という意味ではないですよね？
0977デフォルトの名無しさん
05/03/01 11:48:390978デフォルトの名無しさん
05/03/01 12:11:19嫌悪感を示す人の中で、このパラダイム向け言語処理系をある程度、
まともに使ったことがある人は皆無に近いと思いますよ。
批判的になることで、自ら、その事実を晒してしまっているわけです。
0979デフォルトの名無しさん
05/03/01 12:33:35> 嫌悪感を示す人の中で、このパラダイム向け言語処理系をある程度、
> まともに使ったことがある人は皆無に近いと思いますよ。
ポカーン
英語的に問題あるという話なのに、978は一体何を考えているのでしょうか？
0980デフォルトの名無しさん
05/03/01 12:36:49きっと（ｒｙ
0981デフォルトの名無しさん
05/03/01 16:52:31ん、英語的に問題？ 問題があるのは928（と979）の理解のほうだろ。
インスタンスが「クラスのインスタンス」のコンテキストを意味するのは
自明のことだし、インスタンスベースがオブジェクトベースの同義である
ことはインスタンスがオブジェクトと同義である程度には許されるはずだ。
そして、このパラダイムに則って運用される世の中のオブジェクトのほと
んどが実質、何らかのクラスに属している。つまり、当初、取りざたされ
たようなクラスの有無は、このパラダイムにおいて本質じゃない。
お前みたいのが分かったふりして出てくるのを助長するからプロトタイプ
ベースってのは限定的でマズいって話。これだけ繰り返しても、まだ分か
らないのか？
0982デフォルトの名無しさん
05/03/01 18:33:18自明じゃないだろ。
「クラスのインスタンス」と自分で自明じゃない事を証明してしまってるじゃないか。
アフォか。
0983デフォルトの名無しさん
05/03/01 18:55:58悪かった。このスレ以外では…、と但し書きを入れるのを忘れてたよ。orz
0984デフォルトの名無しさん
05/03/02 00:08:18何を目的としているのだろう。
英語の文献では、prototype basedもしくはclone basedくらいしか
使われていない。英語の意味的にもinstance basedは有り得ない
のだから、変な用語を広めようとするのは止めてくれ。
0985デフォルトの名無しさん
05/03/02 01:18:58どんな文献を読んで言っているんだか…。文献調査が足りてないぞ、学生君。
とりあえず、手近な文献データベースでinstance-based AND object-orientedな
検索かけてみたまえ。話はそれからだ。
0986デフォルトの名無しさん
05/03/02 01:33:060987デフォルトの名無しさん
05/03/02 04:14:22> インスタンスが「クラスのインスタンス」のコンテキストを意味するのは
> 自明のことだし、インスタンスベースがオブジェクトベースの同義である
> ことはインスタンスがオブジェクトと同義である程度には許されるはずだ。
じゃ、その定義によるとSmalltalkはインスタンスベースだな。プゲラ
0988デフォルトの名無しさん
05/03/02 08:18:56検索にヒットしたらそれが正しい用語だと思っているのか？
instance-basedとobject-orientedの両方が含まれているだけの文章が
山程ヒットしているだけで、無関係のものしかないようだが？
ここ10年くらいのまともなプログラミング言語系journal、proceedingsや
それ以前の主要な文献でinstance-basedなんて言葉をいわゆる
プロトタイプベースの意味で使ったものなんか見たこと無いぞ。
0989デフォルトの名無しさん
05/03/02 11:22:27> instance-basedなんて言葉をいわゆる
> プロトタイプベースの意味で使ったものなんか見たこと無い
へえ…
http://portal.acm.org/citation.cfm?id=312023
http://portal.acm.org/citation.cfm?id=141955
http://portal.acm.org/citation.cfm?id=84459
http://portal.acm.org/citation.cfm?id=323737
...
0990デフォルトの名無しさん
05/03/02 18:16:370991デフォルトの名無しさん
05/03/02 19:09:540992デフォルトの名無しさん
05/03/02 19:30:320993デフォルトの名無しさん
05/03/02 19:44:400994デフォルトの名無しさん
05/03/02 19:53:400995デフォルトの名無しさん
05/03/02 19:56:120996デフォルトの名無しさん
05/03/02 19:59:410997デフォルトの名無しさん
05/03/02 20:01:39｜
ト
マ
ン
教
0998デフォルトの名無しさん
05/03/02 20:03:28l ＿,,,,,,,,＿,;;;;i ＜いいぞ ベイべー！
0999デフォルトの名無しさん
05/03/02 20:04:09ゥ
ハ
ハ
ハ
｜
ハ
ァ
｜
1000デフォルトの名無しさん
05/03/02 20:04:201001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。