プロトタイプベース・オブジェクト指向

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 23:17 / Filesize : 368 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

プロトタイプベース・オブジェクト指向

1 名前：デフォルトの名無しさん [03/12/08 21:30]: オブジェクトを複製または継承によって生成を行う言語，
プロトタイプベース・オブジェクト指向言語について語りましょうよ．

関連リンク >>2
446 名前：デフォルトの名無しさん mailto:sage [04/02/12 03:06]: 内部的には Python は CLOS に、Ruby は Smalltalk/Squeak の
それに近いのかな…。つまり、CLOS 、Python はインスタンスと
そのクラスとの関係には手を付けずに、注目するインスタンス専用の
メソッドを用意する。これに対して、Ruby (と、まあ Smalltalk/
Squeak)では元のクラスのサブクラスを作って、注目するインスタンス
のクラスをそれに差し替え、インスタンス特異的なメソッドは差し替え
たサブクラスに定義している。

ちなみに Ruby は構文の工夫や、無名クラスを明示的にしないことで、
さもインスタンスにそれ特異的なメソッドを追加できているように
見せかけているので、ユーザーには
447 名前：デフォルトの名無しさん mailto:sage [04/02/12 11:24]: どうした >>446 ! 何があったんだ!

どうも 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 ならプロトタイプのほうが自然だ ! とかプロトタイプベースのほうが速い! とか言っ
てたような記憶があるのです．やっぱ速いんですかね？
448 名前：デフォルトの名無しさん mailto:sage [04/02/12 11:44]: >>447
書きかけで送っちゃったけど、意味は通じるからいいかなと(笑)。

format はたしかにそうです。馴染みのないひとにも対応付け易い
よう、冗長にしてみました。ご指摘 & 実例たーしゃ。

ついでに Self も parent* スロットには暗示的にアクセスするので、
こちらも parent name などとする必要はなく、単に name だけに
すべきです。
449 名前：デフォルトの名無しさん mailto:sage [04/02/12 14:33]: >>446
> メソッドを用意する。これに対して、Ruby (と、まあ Smalltalk/
> Squeak)では元のクラスのサブクラスを作って、注目するインスタンス
> のクラスをそれに差し替え、インスタンス特異的なメソッドは差し替え
> たサブクラスに定義している。
>
12ﾍｪ～。純粋クラスベースOOの枠組み内でうまいことやってるですね。

ちなみにPythonが冗長なのは、滅多に使わないような機能や生産性にほとんど
影響しないようなところに安易に新しい構文を用意することで、言語が無駄に
複雑化したり初心者を混乱させたりするのは悪である、という思想があるから
のようです。ってプロトタイプとかけ離れてきたのでこの辺で。
450 名前：デフォルトの名無しさん mailto:sage [04/02/14 16:30]: sof.ch/dan/qscheme/intro.html
> Experimental prototype base object orientation.

Scheme 処理系の一つ、QScheme はプロトタイプベースなオブジェクトシステムを
持ってるらしい。
451 名前：デフォルトの名無しさん mailto:sage [04/02/15 17:36]: 結構みんなこのスレ見てるんだね。今日だけでも色んなスレでプロトタイプベースという
言葉を見たよ（以前はそうでもなかったけど）。それともプロトタイプベースの認知度が
上がったのかな。
452 名前：デフォルトの名無しさん mailto:sage [04/02/15 20:59]: www.logtalk.org/features.html

>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 見ていると、色々面白そう。
453 名前：デフォルトの名無しさん mailto:sage [04/02/15 21:04]: で、プロトタイプベースの中で、一番進んだ言語って何？
Ioですか？
454 名前：デフォルトの名無しさん mailto:sage [04/02/15 21:08]: ああ、一番遅れた言語ね。
455 名前：デフォルトの名無しさん mailto:sage [04/02/15 21:23]: MLud もプロトタイプベースだけど、強型付けな ML 上に構築されているという事は、
MLud 自身も強く型付けされた環境なのかなぁ。だとしたらちょっと異色かも。

moonflare.com/code/mlud/index.php
456 名前：デフォルトの名無しさん mailto:sage [04/02/15 21:36]: >>453
言語に大きく依存した機能じゃないから、好きな言語でどうぞっていう流れじゃないかな。
クロージャがあるか、ファーストクラスのメソッドがあれば何とかなる。
457 名前：デフォルトの名無しさん mailto:sage [04/02/16 00:12]: >>453
一番進んでいるのはオブジェクトモデル、VMの性能、クラスライブラリ
の充実度のどれをとってもいまだにSelfだろ。ちょっと古いのと、対象
となるプラットフォームが異常に限られているのが玉に瑕だが。
NewtonScript もかなりよくできていたけど、これはプラットフォーム
自体がなくなっちゃったからなぁ…。

目先を変えて、Scheme の SLIB に含まれる YASOS なんかもいいかもしれない。

ttp://members.at.infoseek.co.jp/zzyyb/scm/slib-ja/slib_2.html#SEC35
458 名前：デフォルトの名無しさん mailto:sage [04/02/16 00:20]: >>456
インスタンス特異的メソッドのみならともかく、委譲機構をそれなりに
実現しようとすると結構な手間になるのでは？
459 名前：デフォルトの名無しさん mailto:sage [04/02/16 00:55]: インスタンスにスロットを持たせるのはなんとなく分かったので、
委譲機構とやらのサンプルコードをキボンヌ。最低限どんな動きが
どれくれーできればいいんだ？
460 名前：デフォルトの名無しさん mailto:sage [04/02/16 02:46]: >>459
既出ですが、これなんかよく説明されていると思います。

ttp://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/seruby/

サンプルコードの書き下ろしは面倒なので勘弁してください。
私自身は、簡単にできるとは思っても言ってもいないので、説明責任もないし(^_^;)。

最低限できればよいのは、委譲先オブジェクトのメソッドを暗示的
(レシーバには見つけられないとき)に、あるいは必要なら明示的 (Self の
resend、Smalltalk 系の super）に起動できて、その際、起動した
メソッドのコード中の偽変数 self には(メソッドホルダではなく)
レシーバを束縛できていること、でしょうか。
461 名前：デフォルトの名無しさん mailto:sage [04/02/17 00:33]: 459じゃないんだけど。
つまり委譲機構ってのは手前で処理できぬメッセージが来たら
プロトタイプチェーンを遡ってメソッドを探す事っつーことですか。
クラスベースだと何に当たる言葉なんだろう。「ポリもアフィズム」じゃないし。

self / this にそもそもメッセージを受けた人が入らないといけないが、
クラスベースなら[[クラスの]]継承階層を遡っていき、クラスとオブジェクトが峻別されるから
あまり問題にならないところだが、
プロトタイプベースだと[[オブジェクトの]]チェーンを遡っていくんだが
でも親のオブジェクトが受けちゃったりしたらまずいって訳だ。

RubyもSelfもわからんので読めん。
漏れの読めるプロトタイプベースはECMAScriptだけでいいや・・・。
462 名前：n [04/02/17 10:11]: 本当にECMAScriptってプロトタイプベースなんですか？
わたしにはろくに継承/委譲ができないように思えるのですが・・・。
463 名前：デフォルトの名無しさん mailto:sage [04/02/17 16:56]: >>462
勉強を兼ねて恒例の 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() + " "); // => 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() + " "); // => 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() + " "); // => 150
document.write( bank_account.withdraw(200).get_balance() + " "); // => 0
464 名前：デフォルトの名無しさん mailto:sage [04/02/17 17:05]: >>463 続き
var my_account = new Object;
my_account.__proto__ = bank_account;

document.write( my_account.set_balance(100).get_balance() + " "); // => 100
document.write( my_account.deposit(50).get_balance() + " ");　// => 150
document.write( bank_account.get_balance() + " ");　// => 0
465 名前：デフォルトの名無しさん mailto:sage [04/02/17 17:07]: >>464　続き
function 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() + " "); // => 10
document.write( stock_account.get_price_per_share() + " "); // => 30
466 名前：デフォルトの名無しさん mailto:sage [04/02/17 17:10]: >>465　続き
function 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() + " "); // => 300
document.write( stock_account.set_balance(600).get_balance() + " "); // => 600
document.write( stock_account.set_balance(600).get_num_shares() + " "); // => 20
document.write( stock_account.deposit(60).get_balance() + " "); // => 660
document.write( stock_account.get_num_shares() + " ");　// => 22
document.write( stock_account.withdraw(90).get_balance() + " "); // => 570
document.write( stock_account.get_num_shares() + " "); // => 19
</script>
467 名前：デフォルトの名無しさん mailto:sage [04/02/17 18:03]: 読み難いソースだなぁ…
468 名前：デフォルトの名無しさん mailto:sage [04/02/17 23:48]: Netscapeで動く。
IEでは動かない。

セッターが必ずthisを返してメッセージをカスケードさせてるのは趣味?
Smalltalk以外でもそうするものなの?

Netscapeのガイド
ttp://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/obj2.html#1013803
だと、コンストラクタ作って、prototypeプロパティに継承元をセットしていて、クラスベースっぽい
469 名前：デフォルトの名無しさん mailto:sage [04/02/18 08:51]: stock_accountの定義はどこ??

var stock_account = new Object;
stock_account.__proto__ = bank_account;
が抜けてる??
470 名前：デフォルトの名無しさん mailto:sage [04/02/18 09:36]: >>469
ああ、すみません。抜けてます。465 と 464 の間に。

>>468
ああ、すみません。Smalltalker なもんですから…。
そうでないと気持ち悪くて…。

>>467
ああ、すみません。初めて書いた JavaScript なもんですから…。
でも、私の責任は１／３くらいです(^_^;)。
１／３は JavaScript のせい、１／３は２ちゃんの改行数制限せいです(笑)。
471 名前：n [04/02/18 10:21]: あう、__proto__を使うのですね、それは反則の方向で（ぇ
確かに__proto__が使えるならプロトタイプベースと呼べるとは思うのですが、
__proto__がなくてもプロトタイプベースなのかなぁ、と感じたのですよ。
472 名前：デフォルトの名無しさん mailto:sage [04/02/19 09:20]: >>470
もう少しJSらしく書いてみたけど、普通にやると多態は駄目。
var BankAccount = new Object;
BankAccount.balance = 200;
document.write(BankAccount.balance + " "); // 200

BankAccount.deposit = function(x) { return this.balance += x; }
document.write(BankAccount.deposit(50) + " "); // 250

BankAccount.withdraw = function(x) {
return this.balance = Math.max(this.balance - x, 0);
}
document.write(BankAccount.withdraw(100) + " "); // 150
document.write(BankAccount.withdraw(200) + " "); // 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 + " "); // 100
document.write(myAccount.deposit(50) + " "); // 150
document.write(BankAccount.balance + " "); // 0
473 名前：デフォルトの名無しさん mailto:sage [04/02/19 09:22]: 続き
var stockAccount = new make_Account;
// Mozilla 系 JS ならば var stockAccount.__proto__ = BankAccount でもいい。

stockAccount.numShares = 10;
stockAccount.pricePerShare = 30;
document.write(stockAccount.numShares + " "); // 10
document.write(stockAccount.pricePerShare + " "); // 30

stockAccount.balance = function(x) { // こんな風にしてみたけど…
　　if(arguments.length) this.numShares = x / this.pricePerShare;
　　return this.numShares * this.pricePerShare;
}
document.write(stockAccount.balance() + " "); // 300
document.write(stockAccount.balance(600) + " "); // 600
document.write(stockAccount.numShares + " "); // 20

stockAccount.deposit(60);
document.write(stockAccount.balance() + " ");
// Error: stockAccount.balance is not a function
document.write(stockAccount.numShares + " ");
stockAccount.withdraw(90);
document.write(stockAccount.balance() + " ");
document.write(stockAccount.numShares + " ");
474 名前：デフォルトの名無しさん mailto:sage [04/02/19 09:29]: stockAccount.deposit(x) でこける。
sumim.no-ip.com:8080/wiki/809 の Io の最初の例と同じで
# つか、上自体 Io の例そのままパクッただけだったり。
既にあるプロパティと同名のメソッドを作れない。
結局 getter, setter になるメソッドを書かないとうまくいかない。
475 名前：デフォルトの名無しさん mailto:sage [04/02/19 10:52]: ついでにhomepage.mac.com/mkino2/oop/chainOfResp/index.html
の 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()

すっきり書けてるほうとは思うけど、どうも…
476 名前：デフォルトの名無しさん mailto:sage [04/02/19 10:54]: >>475 __proto__ 版
var 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()

やっぱりこっちの方がプロトタイプっぽい。
477 名前：デフォルトの名無しさん mailto:sage [04/02/19 13:18]: var app = new Function;
app.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
478 名前：デフォルトの名無しさん mailto:sage [04/02/19 15:46]: 昔なつかし

function 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");};
479 名前：1 [04/02/23 15:58]: soopy版

app = {
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();
480 名前：デフォルトの名無しさん mailto:sage [04/02/25 19:17]: なんか色々中途半端とか言われてるけど、
結局はこれ使って何するのか、だと思うよ。

これ使ったら開発効率が上がりました、
実行効率が上がりました、
保守がしやすくなりました、
ってスタンスのパラダイムじゃないよね。＞プロトタイプベース
趣味？
481 名前：デフォルトの名無しさん mailto:sage [04/02/25 19:51]: >>480
んー Newton Script なんかがまさにそうなんだけど、例えば HTML / XHTML のように
UI + action なんかをさらーっと記述するフレームワークなんかを考えると、ごく当たり前に
プロトタイプベースの発想になったりします。

　<a id="a" onClick="hoge()"> a </a>
　<a id="b" onClick="bar()"> b </a>

なんていうようなものを表現するとき、それぞれにクラスを作るのではなくインスタンス毎に
メソッドを定義して済ませてしまうとか。
482 名前：デフォルトの名無しさん mailto:sage [04/02/25 21:55]: UI + action というか、
すでにインスタンスベースの枠組み(UI + actionはその典型)があって、
それに乗っかる場合、っていう意味だろうか。
なんか受け身で消極的な感じがする。
483 名前：デフォルトの名無しさん mailto:sage [04/02/26 08:19]: マルチスレッドとの相性ってどうなんでしょうか。
484 名前：デフォルトの名無しさん mailto:sage [04/02/26 12:56]: >>482
乗っかるというか、全体を構築するために使ってもいいし (Newton は後者)。
ただ、フレームワークそのものはクラスベースでいいんじゃない、っていう見解は
ある意味当たり前にあって（フレームワークで定義されるものは普通汎用性を持っていて、
個別インスタンスなんて珍しいから）、そういう面では prototype 言語でも内部的に
クラスを使っていたりします。

↑漏れはNewtonScript と SpiderMonkey (Netscape 由来の JavaScript エンジン)位
しか詳しくないので信頼度低いけど。
485 名前：デフォルトの名無しさん mailto:sage [04/03/04 16:33]: ttp://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/C3_1.html
C++でテンプレートによる「修飾」継承という手で爆発を抑えつつ多重分類を実現できそうな気が。
486 名前：デフォルトの名無しさん [04/03/13 12:29]: あげ
487 名前：デフォルトの名無しさん mailto:sage [04/03/19 17:47]: >>480 >>481
保守、ついでに戯言

Delphi の procedure | function 型のプロパティとか、
Java の匿名内部クラスとかでイベントを捕獲するのは、
メソッドをカスタマイズするという点でプロトタイプに通じる考えだと思う。

あると便利、なくてもほかに手段があれば別に困らないかもしれない。
488 名前：デフォルトの名無しさん mailto:sage [04/03/20 01:40]: プロトタイプベース言語の proto ってクラスベース言語の super みたいな物であってますか？
どちらも、元のオブジェクトへの参照を保持しているだけですよね？
489 名前：デフォルトの名無しさん mailto:sage [04/03/20 03:51]: >>488
selfとsuperは同じオブジェクトを指す
490 名前：デフォルトの名無しさん mailto:sage [04/03/20 12:52]: >>489
言語によるかも。
491 名前：デフォルトの名無しさん mailto:sage [04/03/20 13:26]: >>488
SELF のリファレンスマニュアルのこれ、

research.sun.com/self/release_4.0/Self-4.0/Tutorial/Language/SyntaxAndSemantics/Resends.html

なんかみてみてもらうとわかると思うけど、それであながち間違いでもなさそう。

SELF の場合、self は self のままで（まぎらわしいなぁ…）、メソッドの呼び出し記述のほう
に resend を冠する。ただ、これはペアレント（aka proto）スロットが一つのときで、複数ある
ときはそれを明示的にするためにペアレントスロット名をもって resend に代える、とある。

まあ、SELF の話をされてもかなわんよ…という人も多いだろうから、なんか他の言語でも
調べてみることにするか。
492 名前：デフォルトの名無しさん mailto:sage [04/03/22 19:33]: プロトタイプチェインについての覚書（ECMAScript, JavaScript）
ttp://members.jcom.home.ne.jp/jintrick/Personal/d20043l.html#d20_1
493 名前：デフォルトの名無しさん mailto:sage [04/03/24 22:39]: インスタンスを実体、クラスを概念とすると、「継承」というものを現実世界で例えた場合に
プロトタイプベースとクラスベースの、どちらがより簡単で判り易い例えができるんでしょうね

クラスベースはクラス，つまり概念の継承なので、クラスに慣れるとクラスの例は
『クーラーボックスの親はただの箱』みたいでも違和感無いですが、
一般人には？？？な話でしょうし。（ちょっと説明すればわかると思いますが）

逆にプロトタイプの例では特定の個人を例に挙げなければ難しいですし。
（実際にプログラム内で操作するのは「個人」ですから、
実際の例を出せばこちらのほうが俺は判り易いと思いますが）

というかインスタンスとクラスの区別が厳密についてないですね俺 orz
クラスが無い分プロトタイプのほうが簡単ですか？
494 名前：デフォルトの名無しさん mailto:sage [04/03/24 22:41]: > クラスを概念

そこがもーダメなような
495 名前：493 [04/03/24 22:46]: そか orz
判ったつもりで判ってなかったんだな
496 名前：デフォルトの名無しさん mailto:sage [04/03/24 22:47]: ごめん下げ忘れた。逝ってきます。
497 名前：デフォルトの名無しさん mailto:sage [04/03/25 12:02]: >>493
んー。やっぱりプロトタイプベース vs クラスベースという構図が
そも間違っていると思う。プロトタイプベースはよりプリミティブな
オブジェクトモデルなんで、クラスベースがよい仕事をする問題領域なら
機能を制限してそうしたフレームワークを組めばいい（ひらたく言えば
クラスベースを使えばいい）　プロトタイプベースが活きるのは、
クラスベースが到達できない領域なのよ。その最たるものがインスタンス
に独自のメソッドや属性を持たせるってやつで。
498 名前：デフォルトの名無しさん mailto:sage [04/03/25 12:26]: >>497
それは別にクラスベースでもできるでしょう。
例： python, CLOS, 他のにもあるハズ
嬉しいのは「よりプリミティブである」って事だけなの？
499 名前：デフォルトの名無しさん [04/03/25 12:32]: 結局Ruby最強ってことで
500 名前：デフォルトの名無しさん mailto:sage [04/03/29 13:10]: 乙
501 名前：デフォルトの名無しさん mailto:sage [04/03/29 20:36]: 500 名前：デフォルトの名無しさん：sage 投稿日： 04/03/25 (木) 14:16
まえにも見たな、この展開… (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 をひきあいに
だすなっちゅうの。わざとか？
502 名前：デフォルトの名無しさん mailto:sage [04/03/29 20:41]: 504 名前：デフォルトの名無しさん：sage 投稿日： 04/03/25 (木) 18:00
>>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
形から入る人が多そうなスレですね
503 名前：デフォルトの名無しさん mailto:sage [04/03/29 20:48]: 508 名前：デフォルトの名無しさん：sage 投稿日： 04/03/25 (木) 19:28
> オブジェクトが扱える範囲でよりプリミティブであることは
> いいことなんでないの？ようわからんけど。

小さい事は良い事!ってなミニマリストにはそうだろうがねぇ．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はその具体例かな。
# ただインスタンスにメソッドを追加して回ってるだけなんだけどね。
504 名前：デフォルトの名無しさん mailto:sage [04/03/30 01:19]: 512 名前：デフォルトの名無しさん Mail： sage 投稿日： 04/03/25 23:13

そして、言語の動的側面を勘違いした椰子が現れて…　まわるぅ～まわるぅよ(ry

513 名前：デフォルトの名無しさん Mail： sage 投稿日： 04/03/25 23:46

一見ループに見えるが完全に同じではない．循環を断ち切れる事を願ってるんだYO!!

>>509 の意見とか初耳のような気がするぞ．他人の作った生きているオブジェクトを改良できる？
それはプロトタイプベースの特徴なのか？しかし浅学故，それがどうプロトタイプベー
スと関連するのかわからない．オブジェクトの受け渡しと特異メソッドが必要だがプ
ロトタイプベースとは関係ないんじゃ？と思うんだけど違うのかな．

今のところ

1. 「クラス」がないからシンプル
2. 「クラス」がなくても同等の機能（…なの？）

くらいしか理解してないんだが．どうもプロトタイプならではってウリが見えないわ
け．インスタンスのコピーはクラスベースだと苦労が多いけど，プロトタイプベース
にしたら楽になるのかな？コピーの深さの問題はどうしようもない気がするんだけど．

514 名前：デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:05

>>513
循環してるのは一部の人の頭の中だけだと思うよ。それを断ち切りたいなら、
何か言語いじってみれ。
505 名前：デフォルトの名無しさん mailto:sage [04/03/30 01:20]: 515 名前：デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:34

>>513
プロトタイプベースでは、それなりの規模のシステムではたいてい、トレイトと呼ばれる
クラスベースのクラスと同じ枠組みを作ってそれを使っています。したがって、クラスが
なくても同等…というのは（解釈のしかたにもよりますが）当たりません。

こうした状況はクラスベースの Ruby が特異メソッドを用意しているのと似ていますね。
違いを際だたせるとすれば、Ruby にあるプロトタイプベースの側面は、特異クラスという
ちょっとトリッキーな方法で実現されているのに対して、SELF などでのトレイトは、言語
自体には手を加えずに実現されてているというところでしょうか。

余談ですが、SELF には　Ｒｕｂｙ　とまったく同様の目的と機能を持つミックスインすら
Ruby よりはるか以前からエンティティとして実装しています。それも、言語仕様には
まったく手を加えずに、です（もっとも、トレイトとミックスインの違いは、継承があるか
無いかの違いだけなわけですが…）。

何度か出ていますが、プロトタイプベースのメリットは、通常は言語仕様として出来合で
エンドユーザー（つまりプログラマ）が変更不能な部分を開放したかたちで処理系が提供
されている（できる）ことではないでしょうか。511 さんの言う「自分で改良できる」という
ニュアンスにはそんなところも含まれているように感じました。

これは、Smalltalk が処理系全体を Smalltalk 自身で記述し、エンドユーザーが自由に
閲覧、変更、拡張ができるようにしているのと似ていなくもないですね。ただ、SELF の
場合は、Smalltalk では変えられない部分も（たとえば、クラスとインスタンスの関係と
いったプリミティブな部分も） SELF 自体でトレイトフレームワークとして表現されている
ために、エンドユーザーが到達可能…というわけです。

Ruby の例に戻ると、仮に特異メソッドやミックスインの振る舞いに不満を感じても、まつ
もとさんを説得するまで仕様の変更は不可能です。しかし、プロトタイプベースなら自分の
好きに変えてしまえばよいのです。もっとも、これをミニマリズム、動的側面のメリットのとり
違い…と言われてしまえばそれまでですが。
506 名前：この先、誰か持ってない？ mailto:sage [04/03/30 01:21]: 516 名前：デフォルトの名無しさん Mail： sage 投稿日： 04/03/26 00:43

>>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以外にどんな機能が実現可能か妄想したりするスレとかには……ならないなｗ
507 名前：デフォルトの名無しさん mailto:sage [04/04/02 06:23]: プロトタイプベースな言語で分散オブジェクト環境を構築するのって
結構大変そうっていうかパフォーマンスが苦しそう。
508 名前：デフォルトの名無しさん mailto:sage [04/04/02 12:09]: >>507
うん・・・でもパフォーマンスを考慮した従来型の ORB や RPC に代わって
SOAP とか出てきてる世の中だからなぁ。
509 名前：デフォルトの名無しさん mailto:sage [04/04/03 01:41]: sage ：04/03/26 01:23
プログラム / プロトタイプベース・オブジェクト指向 - 情報

Lispがプリミティブなλ計算そのものだから何でもできるように、
プロトタイプは、OOについてプリミティブだから何でもできる、でいいの？

モノがほかのモノをプロトタイプとして持つってすごく変なモデルの気がするけど、
λ計算みたいに、数学的な意味を持ったモデルなんでしょうか。

プロトタイプがプリミティブたるOOモデルというのが多分数学的にあって、
クラスベースもその中にすっぽり入ってしまうんだと思います。
そういう、本物のOOの定義モデルが実はあるような気がします。
どの言語の何がOOの起源でObjectとはどうだこうだ、というレベルではなくて、
本物のOO定義モデルが。

制約は普通の手続き言語なんかそのものですよね。
チューリングモデルを制約することで使いやすくしているという意味で。
510 名前：デフォルトの名無しさん mailto:sage [04/04/03 02:24]: >>509
まんどくさいから、その辺からツッコミ直してみる。

> どの言語の何がOOの起源でObjectとはどうだこうだ、というレベルではなくて、
> 本物のOO定義モデルが。

prototype baseなモデルMpとclass baseなモデルMcを定義できたとして、
Mp上に仮想Mcを構築できて、なおかつ、Mc上で仮想Mpを定義できれば
どっちが本物とは言えなくなる罠。

と言うと、オッカムの剃刀と言い出す香具師がいるかもしれんが、
OOの全ての機能をObjectに集中させたのがprototype baseで、
オブジェクトの種類という視点では一番簡便になる。
一方、class baseではオブジェクトの生成とオブジェクトの働きを別々に記述するが
これは各機能をより純粋にモデリングしたということでもある。

> 制約は普通の手続き言語なんかそのものですよね。
> チューリングモデルを制約することで使いやすくしているという意味で。

これについては、そうは思わない。
チューリング機械は現代のプログラミング言語よりも表現上の制約を受けている。
つーか、チューリング機械なんて、ヘッドの左右への動きとヘッド位置にある
シンボルの置き換えでしか表現できないんだから、これ以上制約したら
ほとんど何もできなくなる罠。
511 名前：デフォルトの名無しさん mailto:sage [04/04/03 16:59]: > Mc上で仮想Mpを定義できればどっちが本物とは言えなくなる罠。

これが出来ないんじゃないのかな、
というのが上のレスと思われ。

> チューリング機械は現代のプログラミング言語よりも表現上の制約を受けている。
これについては、そうは思わない。
チューリング機械は現代のプログラミング言語の表現のどのようなモノも、
（表現が長たらしくなるが）表現できる。逆に、
現代のプログラミング言語はチューリング機械の表現のどのようなモノも、
（言語機能と同レベルで）表現できるとは限らない。
「言語機能と同レベルで」ってのはチューリング機械自体をエミュる層をわざわざ作らずに、ということ。
512 名前：デフォルトの名無しさん mailto:sage [04/04/03 17:23]: >>511
> > Mc上で仮想Mpを定義できればどっちが本物とは言えなくなる罠。
>
> これが出来ないんじゃないのかな、
> というのが上のレスと思われ。

クラスベース環境上にプロトタイプベース環境を構築した例など腐るほどあるが。

> 現代のプログラミング言語はチューリング機械の表現のどのようなモノも、
> （言語機能と同レベルで）表現できるとは限らない。

現代風のプログラミング言語で実現できない例を挙げてみなよ。
つーか、とりあえず構造化プログラミングの論文でも読んでみれば？
513 名前：デフォルトの名無しさん mailto:sage [04/04/03 17:54]: > クラスベース環境上にプロトタイプベース環境を構築した例など腐るほどあるが。

ああ、まったくそのとおり。ずばりエミュだもんな。ぼけてた。
これについては>>510の通り。

> 現代風のプログラミング言語で実現できない例を挙げてみなよ。

チューリングマシンのコーディングは漏れは出来ないけど、
関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？
514 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:03]: まあ、何が言いてぇかっつうと、
Lispだとプリミティブな計算モデルそのものだから、
任意の言語モデルを作って使えるみたいに、
プロトタイプはプリミティブなOOモデルそのものだから、
任意のOOモデルを作って使えるんじゃないかな、という妄想。

まあ、そのためには記法の問題っつうか、
Lispのマクロ相当がないとそのままは使えないけど。
515 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:22]: プロトタイプ機構？　(ﾟДﾟ)ﾊｧ？そんなの余計なお世話。
こんなお仕着せの機構で成り立ったシステムがプリミティブだなんて
あり得ねぇよ。クラス機構と目糞鼻糞。
516 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:25]: >>513
> 関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？

そんなことはチューリングマシンでもできん罠
517 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:40]: チューリングマシンに関数なんてない、
だから相当するモノを作ることになる。
で、自分で作るんだから、
> 関数Aのn行目から任意の関数Xのm行目にジャンプするってできないじゃん？
が出来るように作ればいい。schemeで似た事出来るし、出来るでしょ。

はNG？
518 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:47]: >>515
プログラムコードの再利用機構って意味では、委譲ベースでも継承ベースでも
どっちでも良いな。相互排他的な物でもないし。
どっちも無いと困るけど。

肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
変数のスロットはインスタンスローカルで持てるのに、メソッドのスロットを
インスタンスローカルで持てないのって不便。
519 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:49]: >>518
> 肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
> 変数のスロットはインスタンスローカルで持てるのに、メソッドのスロットを
> インスタンスローカルで持てないのって不便。

それ、Smalltalkでは動的にどうとでもできるって話が出てなかったか？
520 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:51]: >>517
エミュるんだったら、プログラミング言語でもエミュるのアリにしないとな。
521 名前：デフォルトの名無しさん mailto:sage [04/04/03 18:59]: >>520
論理的な問題じゃなくて、実際的な問題。
チューリングマシンは概念がないから概念をエミュってなんぼのモノ。
プログラミング言語は、エミュらなくてもすぐ概念を使えるようにしているモノ。
用途で考えれば、プログラミング言語でもエミュるのは無意味。
エミュって概念壊したらプログラム言語の意味ないじゃん。
522 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:02]: >>519
別クラスを生成して become するって話？
それともブロッククロージャを変数に代入してコールするとかかな。
523 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:04]: > 肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
どういう意味でキモなのかわからん。
委譲ベースとか継承ベースとかと関係が見えない。

とりあえず、リフレクション最強、
と言っておけばいいのか？
524 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:15]: >>523
>> 肝はオブジェクト生成後にメソッドの再定義を受け付けるかどうかだと思う。
>どういう意味でキモなのかわからん。
>委譲ベースとか継承ベースとかと関係が見えない。

コードの再利用機構　　ーー＞　　どうでも良い
メソッドの再定義可能性　　ーー＞　　こっちが重要

リフレクションは実現方法の一つに過ぎないと思う。
525 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:15]: >>518
いやいや、メソッド呼び出しとは何かの定義次第だから、
どっちもなくていいでしょ。それを定義できればいいんだから。
つまるところ、CLOSを産んだLisp最強ってことで。
526 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:18]: >>524
なる。でもそれは必要なのは、
メソッド再定義可能性、じゃなくて、>>525の呼び出しの定義では？
委譲ベースでの定義　自分を捜して、なければプロトタイプから探す
継承ベースでの定義　自分のクラスを探して、なければクラスの親から捜す。
これ以外にもあり得るでしょ。
527 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:24]: 結局、プリミティブなOOモデルなんて存在しねぇと。
クラスベースもプロトタイプベースも目糞鼻糞。
528 名前：デフォルトの名無しさん mailto:sage [04/04/03 19:38]: >>525-526
なるほど、そうですね。

>それを定義できればいいんだから。

までは考えてませんでした。

>自分を捜して

というのがあれば自分的には嬉しいです。

Scheme みたいに、シンボルに束縛されているのが値か手続きか区別しない（
評価する時に S 式の頭にあれば手続きと看做される）ようなモデルがｲｲですね。
メソッドテーブルはクラスに属し、変数テーブルはインスタンスに属するという
のは実装上の都合ですよね。これは一貫性に欠けると思います。特にメソッドが
ファーストクラスなら、尚更。
529 名前：デフォルトの名無しさん mailto:sage [04/04/03 20:04]: >メソッドテーブルはクラスに属し、変数テーブルはインスタンスに属するという
>のは実装上の都合ですよね。
実装って言うか、それがクラス、なのかな？
うーん、クラスってなんだろ。

欲しいのは、
自分を捜して、なければ自分のクラスを探して、なければクラスの親から捜す、
っていう感じ？
しらんけど、Rubyってこんなんじゃない？
530 名前：デフォルトの名無しさん mailto:sage [04/04/03 20:17]: 消えたログの続きが読みたい・・・。
>>509 は >>506 の続きになるのかな。
531 名前：デフォルトの名無しさん mailto:sage [04/04/04 00:57]: >>529
メソッドに話を限れば、クラスは、オブジェクトにとって

・原則として変更が許されない
・無条件移譲先

ですね。逆に言えば、プロトタイプベースのオブジェクトにこのような
制約を課すことで、オーソドックスなクラスベースのオブジェクトが
できあがるわけです。縛りを緩くすれば、プロトタイプベースの要素を
盛り込むことができます。
532 名前：デフォルトの名無しさん mailto:sage [04/04/04 01:22]: >>531
さらに、自分が委ねられたメソッド起動リクエストについては、無条件委譲先
ではなく、あらかじめ別に用意した移譲先に委譲する…という縛りを設ければ
より完全にクラスベースの振る舞いをさせることができそうです。

たとえば、Smalltalk のクラスは（インスタンス）メソッドを持っていますが、
それらはインスタンスから委譲された場合のみ起動でき、自分で起動する
ことはできません。これは先の無条件委譲のしばりが効いていると考えるとうまく
説明できます。また、インスタンスから委譲されたが自分は持っていない
メソッドについては、ここで述べた「自らがレシーバでないときは、無条件
移譲先に委譲できない」という縛りから、二つある委譲先スロットのうち、
無条件移譲先には委譲できず、もう一方、つまりスーパークラスへ委譲せざるを
得ない、というふうに解釈すればよいわけです。
533 名前：デフォルトの名無しさん mailto:sage [04/04/04 01:28]: >>532
このようなメソッドディパッチの観点から言うと、CLOS はそもそも
メソッドがオブジェクトに属しておらず、クラスベースでもプロトタイプ
ベースでもないので、ちょっと脇によけておいた方がよさそうですね。
534 名前：デフォルトの名無しさん mailto:sage [04/04/04 01:39]: じゃ、クラスベースはどんな制限をつけるとプロタイプベースになるの？
535 名前：デフォルトの名無しさん mailto:sage [04/04/04 03:08]: >>534
クラスのインスタンスが常にひとつであるような制約を課すことで(見かけ上の)
プロトタイプベース・オブジェクトを実現できます。

たとえば、Smalltalk のようにクラス自身もオブジェクトで、かつ、メタクラスの
シングルトンであることが保証されている言語なら(非クラスの)インスタンスを
使わず、クラスを使うことでそのままプロトタイプベースプログラミングが(見かけ上)
可能です。

インスタンスに直接メソッドをもたせるような機構にしなければならないのならば、
制約を課すだけでは駄目で、薄いながらも何かしらレイヤーを書いてやる必要が
あるでしょう。
536 名前：デフォルトの名無しさん mailto:sage [04/04/04 05:37]: >>528
> Scheme みたいに、シンボルに束縛されているのが値か手続きか区別しない（
> 評価する時に S 式の頭にあれば手続きと看做される）ようなモデルがｲｲですね。

スレ違いだが、それはどうだろうね。
変数名とメソッド名への制約が増えるから、俺は嫌いだね。
537 名前：デフォルトの名無しさん mailto:sage [04/04/05 16:15]: えーと、「出来ます」ってだけだと、そりゃある程度強力な言語ならあちてい何でもできるわけで、
インスタンスベースのスロットの定義等について、その機構をサポートする簡易な文法があって、
便利に利用できるってことが重要なんじゃない？

例えば、プロトタイプ言語で
human = [ kind: #human, bark() { print("I'm human");} ];
anAho = [ _proto: human, iq: 100, bark() : { print("My name is aho");} ];
とか２行でかけるものを、何行も文を連ねて書いて「出来ます」ってのはなんか違うっていうか・・・
538 名前：デフォルトの名無しさん mailto:sage [04/04/06 02:08]: >>537
簡単なオブジェクトを簡単に記述できるというのは、
スクリプト言語ならば重要な問題かもしれんが、
環境がベースになっている言語ではあまり本質ではないね。
つまり、スクリプト言語に使うのならメソッドを2,3定義するだけでいいものが多いから
1行や2行で書けるかどうかが問題になるが、もっと環境を使ってライブラリ蓄積
していくことを想定した言語では、そういった1行コードは問題ではない。

あと、Modula-3のopaque typeのように一見煩雑に見えるけど
言語機能としてはそれなりに洗練された結果というものもある。
539 名前：デフォルトの名無しさん mailto:sage [04/04/06 06:41]: >>537

流行ってないんでしようがないのだけれども、こういうのはある意味典型的な
プロトタイプ言語のコードなわけで、なんてのかな、>>535の前半のような発想よりは
むしろ↑の方で出てきたクロージャでインスタンスを実現するものの方が指向が
近しいような気がする、というか。。

>>536
>スレ違いだが、それはどうだろうね。
たぶん殆どのプロトタイプ言語でその区別は行われていないと思います。
好き嫌いはともかく。
540 名前：デフォルトの名無しさん mailto:sage [04/04/06 07:23]: >>537-539
あのー、いつの間にモデルの話からリテラル表現の話に飛んでいったのでしょうか？
あと、当然ながら処理系の設計の話もまた別の話だ罠。
541 名前：デフォルトの名無しさん mailto:sage [04/04/07 13:17]: モデルの話は結論？まで逝ったからいいでしょう。>>537-539は解ってなさそうだけど。
ところで、POOとUMLの関係ってどうなん？
542 名前：デフォルトの名無しさん mailto:sage [04/04/07 14:26]: >>532
> さらに、自分が委ねられたメソッド起動リクエストについては、無条件委譲先
> ではなく、あらかじめ別に用意した移譲先に委譲する…という縛りを設ければ
> より完全にクラスベースの振る舞いをさせることができそうです。

それだと、メタ方向の委譲とスーパー方向の委譲が混ざらないか？
543 名前：!532 mailto:sage [04/04/08 01:10]: >>542
メタ方向ってインスタンス←クラス←メタクラスの関係の事？
スーパー方向はインスタンス←クラス←スーパークラスだよね。

>>532
で、>>532 が言ってるのは、foo.bar() で foo のクラス Foo がメソッド bar() を
持っていない時、クラス Foo は（Foo 自身のクラスである） MetaFoo に問い
合わせずに、別に用意されたクラス SuperFoo に問い合わせに行くようにする。
MetaFoo に行くか SuperFoo に行くかは、自分がレシーバかどうかで判断する。

・自分がレシーバの時は自分のクラスに問い合わせる（自分がクラスならメタクラス
　に問い合わせる　ーー　そんなケースあるのかな？）
・自分がレシーバじゃない時はスーパークラスに問い合わせる

であってます？

自分がレシーバじゃないってどう判断するのかな？

プロトタイプチェーンが分かっていないので、変な事を言っていたら済みません。
544 名前：デフォルトの名無しさん mailto:sage [04/04/08 02:20]: 処理系の実装が複数あって、仕様がある程度きっちり決まっているプロトタイプベース
言語って JavaScript 以外にあります？
545 名前：デフォルトの名無しさん mailto:sage [04/04/08 08:33]: >>543
そういう制御をしようとしたら処理系自体に手を入れないと話にならんでしょ
546 名前：デフォルトの名無しさん mailto:sage [04/04/10 05:25]: Smalltalk の SomeClass allInstances do: [foo_proc] みたいなイメージで、
あるプロトタイプを共有しているオブジェクト全てにメッセージを送信する
機能を持っているプロトタイプベース言語ってありますか？
547 名前：デフォルトの名無しさん mailto:sage [04/04/10 22:54]: >>546
細かいようですが、SomeClass allInstances do: [:inst | inst somethingToDo] ですね。

で、本題は SomeClass allInstances みたいなものがあるか？
ということでよろしいですか？　それなら元祖的存在の SELF にすでに
browse childrenOf: obj
というのがあります。プロトタイプスロットに obj を束縛している
全オブジェクトをリスト(a vector) で返します。
548 名前：デフォルトの名無しさん mailto:sage [04/04/11 21:24]: >>547
どうもありがとうございます。

オブジェクト生成する毎に辞書に登録してるのかしらん。
プロトタイプベースの言語は個々のオブジェクトは野放し状態だと
思ってましたが、ある程度の管理はされているんですね。
549 名前：デフォルトの名無しさん mailto:sage [04/04/12 02:43]: >>548
ん～、でも、Smalltalk においても #allBehaviorsDo: なんかは本来はオブジェクト全部に
問い合わせたりするのがスジだったりするので（高速化のための端折っていますが）
クラスベース、インスタンスベースに限らず、全オブジェクトがオブジェクトメモリ内にあるか、
さらに、それらにアクセスする手段があるか否かってところで、allなんたらな機能が存在しうる
かどうかが決まってしまうような気もします。

まあ、純粋なオブジェクト指向（そんなものがあればの話ですが…(^_^;)）を論ずるとき、
実装において、高速化や最適化がからむ部分は解釈が難しいですね。たとえば、
消えてしまったログの object-oriented pointer で表現されるオブジェクトには“状態”
はあるかないか…なんて話とかもそのたぐいだと思います。
550 名前：デフォルトの名無しさん mailto:sage [04/04/12 03:15]: >>549
> まあ、純粋なオブジェクト指向（そんなものがあればの話ですが…(^_^;)）を論ずるとき、
> 実装において、高速化や最適化がからむ部分は解釈が難しいですね。たとえば、
> 消えてしまったログの object-oriented pointer で表現されるオブジェクトには“状態”
> はあるかないか…なんて話とかもそのたぐいだと思います。

まったくです。正確には、オブジェクトの定義に「状態」は本質かどうか、ですね。

私としては、参照透明なオブジェクト世界が可能である以上は
「状態」は本質ではないと思うのですがね。
オブジェクトを「状態」と「機能」で定義しようという考え方というのは
ノイマン型計算機モデルをそのまま小さくして「オブジェクト」にしているんじゃないか
と思います。
551 名前：デフォルトの名無しさん mailto:sage [04/04/15 00:40]: 参照透明性とは直接関係ないけど、関数型言語の返り値を使って演算していくスタイルは
結構好き。
オブジェクト指向言語は一時変数を作りまくるというイメージがあります。Smalltalk とか、
文法的には返り値を使うスタイルでも全然問題無さそうなのになぁ。

Lisp と Smalltalk を足して２で割った様な言語が欲しい。Self がそうかと思ったけど、
どうなんでしょう？
552 名前：デフォルトの名無しさん mailto:sage [04/04/15 00:45]: >>551 OCamlは？
553 名前：デフォルトの名無しさん mailto:sage [04/04/15 00:53]: >>552
dynamic binding な言語が好きなもので。すいません。
554 名前：551 mailto:sage [04/04/19 04:21]: Slate ﾊｹｰﾝ！

slate.tunes.org/

以前このメールを見た時は、サイトに繋がらなかったのに。

ttp://www.sra.co.jp/smalltalk/SML/archives/2002-October/005955.html
555 名前：デフォルトの名無しさん mailto:sage [04/04/19 12:27]: C++ の operator() および、 boost::function などの汎用関数オブジェクトは、
型にとらわれない柔軟な仕組みだと思う。C++ は静的でありながら、工夫次第で
動的拡張も可能なモンスター言語だとおもう。

myObject.Connect( "Proc", MyFunction ); // MyFunction をスロットにセット
( myObject->*"Proc" )( 24 ); // MyFunction 呼び出し

とかも出来る。しないけど。
556 名前：デフォルトの名無しさん mailto:sage [04/04/19 18:54]: 言語は色々勉強した方がいいよ。
557 名前：デフォルトの名無しさん mailto:sage [04/04/19 19:15]: Delphiのカスタムバリアント(ﾎﾞｿ
558 名前：デフォルトの名無しさん mailto:sage [04/05/05 10:41]: Self 4.2.1 がリリースされていますね。

ttp://research.sun.com/self/release_4.2/release.html
559 名前：1 mailto:sage [04/05/21 21:31]: hosyu
560 名前：デフォルトの名無しさん [04/06/02 18:37]: どうした？
おまえら。
561 名前：デフォルトの名無しさん mailto:sage [04/06/05 00:19]: selfってWindowsかLinuxじゃ使えないの？
562 名前：デフォルトの名無しさん mailto:sage [04/06/05 22:20]: >>561
一応、あるにはあるのですが…。古いので動かすのは難かしいかも。

ttp://www.gliebe.de/self/
563 名前：デフォルトの名無しさん mailto:sage [04/06/09 18:22]: 今使うならJavaScript一択でしょ。
564 名前：デフォルトの名無しさん [04/07/03 01:38]: プロトタイプベース晒しage
565 名前：デフォルトの名無しさん mailto:sage [04/07/05 03:52]: >>563
一応IoやSmalltalk（Squeak）でもいいんじゃない？
566 名前：デフォルトの名無しさん mailto:sage [04/07/06 14:58]: あれ、だれもProthonに触れないの？
海外で結構人気らしい。
www.prothon.org/index.html
567 名前：デフォルトの名無しさん mailto:sage [04/07/15 11:51]: >>565
こら! Smalltalkはクラスベースだろ。それをプロトタイプベース
に改造した「始祖」がSelfだ。
568 名前：デフォルトの名無しさん mailto:sage [04/07/15 12:23]: アホが一匹紛れ込んでいるので引き取ってください
C＃って死滅する理由がないよね！ Part4
pc5.2ch.net/test/read.cgi/tech/1042464104/639
569 名前：デフォルトの名無しさん mailto:sage [04/07/15 20:31]: >>567
タイルスクリプティング（だっけ？）の部分じゃないの。
570 名前：デフォルトの名無しさん mailto:sage [04/07/16 08:05]: >>569
それはSmalltalkじゃなくてSqueakな…
いってみれば「Cは統合ヘルプ環境がいい」と同じぐらい変。
571 名前：デフォルトの名無しさん mailto:sage [04/07/16 10:47]: >>570
>>565 に Squeak って書いてあるじゃん。
572 名前：デフォルトの名無しさん mailto:sage [04/07/16 11:54]: うち誰かがSqueakシステムにおける、Squeak eToysとSmalltalk言語の区別が
できていない罠。

eToysはSmalltalk言語で記述されているが、Smalltalk言語とは別物の
言語処理系。プロトタイプベースだし、変数には型があり、if-then-elseの
条件分岐構文もある。

ふつう、Squeakと書けば（Smalltalkが併記された場合はなおさら）「Squeakシステム」を、
Smalltalkと書けば「Smalltalk言語」をイメージさせるから「Smalltalk（Squeak）」と
書いてもSqueak eToysを意図しているとは受け取られにくい…

のであります。
573 名前：デフォルトの名無しさん mailto:sage [04/07/16 12:06]: 俺はむしろ、わざわざ Squeak と併記したのは、Morph とかタイルスクリプティングを
匂わせたかったのかと思ったよ。まぁ、好意的な解釈かもしれんが。
574 名前：デフォルトの名無しさん mailto:sage [04/07/16 13:50]: >>573
むしろ？　わざわざ？
575 名前：デフォルトの名無しさん mailto:sage [04/07/17 01:28]: 子供かよ。
576 名前：デフォルトの名無しさん [04/07/19 14:47]: Hage
577 名前：1 mailto:haskellsaikou [04/08/12 00:25]: クラスベースに比べると、記述量的に見てプロトタイプベースは厳しいですかね。

最近Haskell勉強してるんですけど、
「頻繁に使用する少数の道具」が揃っているところが強みだと感じています。
再帰系の高階関数とかコンビネータとか。

そういう厳選された道具がオブジェクト指向の世界にも存在するのかなぁ。
もしあればそれを探し出して、組み込んだ言語ならクラスベースに匹敵するかも。

Lightweight Language が流行っているように
如何に簡単に多くのことを行えるか、がこれからの言語争いで重要だと思います。
# 言うまでもないけど
578 名前：デフォルトの名無しさん mailto:sage [04/08/18 02:59]: 実際ゲームのスクリプトなんかに向いてるみたい。
diablo2 のjspというBOTはjavascript。
まあまあ使いやすかった。
プロトタイプベースである必要はあんまない気がするが。
579 名前：デフォルトの名無しさん mailto:sage [04/08/18 08:11]: というか、使う人が手を入れることを前提とする場合クラスよりもプロトタイプのほうが扱いやすい。
580 名前：デフォルトの名無しさん mailto:sage [04/08/18 15:41]: HTML に埋め込むタイプの小規模スクリプトだと、プロトタイプの独壇場。
581 名前：デフォルトの名無しさん mailto:sage [04/08/18 16:44]: >>580
ボタンや IMG の挙動を変えるのにいちいち別クラスにしたくないな、確かに。
582 名前：デフォルトの名無しさん mailto:sage [04/08/18 22:00]: 構文的な言語の特殊性としては、
やっぱJavaScript程度のものが妥当なんだと思った。
LispやSmalltalkみたいな変則的なものは知ってる人じゃないと近寄りがたい。
手軽にtarget.xとかドット表記でオブジェクトを指定できるのもいい。
なんだかんだ言ってもCかPerlなら知ってる人多いからね。
jspのスクリプトがあそこまで普及したのはライブラリの質の高さもあったけど、
構文的なわかりやすさが影響してると思う。
プロトタイプベースとあんま関係なくてごめん。
583 名前：デフォルトの名無しさん mailto:sage [04/08/22 00:46]: もまいらが使ってるプロトタイプベース言語で数行程度のサンプルコード書いてみてくれないか？
584 名前：デフォルトの名無しさん mailto:sage [04/08/22 01:12]: >>583
何か興味あるところで“お題”を出してもらえればすぐに。
でなければ、普段使っているクラスベースで数行のサンプルを
提示してくれれば、それと同等のものを書きます。
585 名前：デフォルトの名無しさん mailto:sage [04/08/22 02:48]: >>583

INU:
[ "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!
586 名前：デフォルトの名無しさん mailto:sage [04/08/22 16:03]: class Thread2ch {
static 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氏早速ありがとうございます
587 名前：デフォルトの名無しさん mailto:sage [04/08/22 16:14]: >>586
それのドコがプロトタイプベースやのん？
588 名前：デフォルトの名無しさん mailto:sage [04/08/22 16:30]: >>587 に同意。もう少しプロトタイプベースっぽいお題でないと。
というわけで >>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!

犬の派生に猫ってのも妙だけどなー。
589 名前：585 mailto:sage [04/08/22 18:25]: >>586
ほとんど知る人のない梓弓スクリプトという言語です。
なんとか直訳的に写すとこんな感じかなあ。でも、
>>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 犬」だから
クラス・インスタンス関係みたいになってちょっとかな…と。
590 名前：デフォルトの名無しさん mailto:sage [04/08/22 18:34]: 流れを断ち切るようで申し訳ないのですが
プロトタイプベースは、親のスロットを変更すると子にまで影響及ぶんでしたっけ？
591 名前：デフォルトの名無しさん mailto:sage [04/08/22 18:41]: >>590
デリゲーションチェインがあればどうなるかは考えればわかるだろ
592 名前：デフォルトの名無しさん mailto:sage [04/08/22 18:50]: >>590
言語によりけりじゃないのかなあ？
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
593 名前：590 mailto:sage [04/08/22 19:07]: >>591 >>592
親のスロットを変更した際の挙動がプロトタイプベースの定義に
含まれているか知りたかったんでス
即レス㌧くすでした
594 名前：デフォルトの名無しさん mailto:sage [04/08/23 21:04]: >>586
なにかと思ったら、プロトタイプベースで書いて欲しいコード
だったんですね。仮想関数あたりはモディファイしてあります。

#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
595 名前：デフォルトの名無しさん mailto:sage [04/08/24 00:21]: 梓弓スクリプトってなんじゃググっても無いぞ
596 名前：デフォルトの名無しさん mailto:sage [04/08/24 00:43]: 今時は誰でも俺言語の一つくらいは持ってるだろうから、その類いじゃね？
597 名前：1 mailto:sage [04/08/24 00:50]: soopyです。
てこんな単純じゃ言語の特徴あまり出ませんね。

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 ();
598 名前：デフォルトの名無しさん mailto:sage [04/08/24 00:56]: >>595
ぐぐったら下のほうに出てきたけど、>>596の類いだな。
まあなんか高い志掲げてるし、将来に期待すれ
599 名前：デフォルトの名無しさん mailto:sage [04/08/24 12:41]: ごめん、例の俺言語の類だが宣伝させてくれ
人少なすぎで少し困ってる
微妙にプロトタイプベースじゃないが勘弁

# 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;
600 名前：599 mailto:sage [04/08/24 12:41]: 続き

# 実行結果
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
601 名前：586 mailto:sage [04/08/24 15:28]: なんだかしょぼいお題コードを書いてしまったようで･･･
Javascriptあたりから出直してきます。＿|￣|○
602 名前：デフォルトの名無しさん mailto:sage [04/08/24 20:20]: >>598
ググって出てきたの？

「梓弓スクリプト」でググったら該当無し
「梓弓スクリプト」でググってもそれらしいのは見当たらず
「梓弓 script」も同様
「梓弓」だけじゃワケワカメだった。

ちょっと興味があるんでキーワード教えてくださいな。
603 名前：デフォルトの名無しさん mailto:sage [04/08/25 00:01]: >>602
「梓弓スクリプト」でぐぐると、
三つめくらいに時候の挨拶っていうのがあって、
そこからリンクたどると見つかるよ。
604 名前：デフォルトの名無しさん mailto:sage [04/08/25 04:57]: 別に無断リンク禁止サイトではないのだから
ずっと時間が経ってからスレを見る人のために
ちゃんとリンクしたほうが良いと思いませんか？

梓弓について
gr.vxx.jp/azusayumi.html
リンクに関する見解
gr.vxx.jp/link.html
605 名前：デフォルトの名無しさん mailto:sage [04/08/25 08:36]: なんで記号的、全時代的な構文のスクリプトばっかなんだ？
Ruby厨と言われるかもしれないけど、RubyのようにクラスベースOOの人でも
違和感無く扱えるような構文の方が良くない？
606 名前：デフォルトの名無しさん mailto:sage [04/08/25 08:43]: >>605
もっと具体的に
607 名前：デフォルトの名無しさん mailto:sage [04/08/25 08:57]: >>603-604
ありがとん
608 名前：デフォルトの名無しさん mailto:sage [04/08/25 09:12]: >>605
スクリプトに限らず俺言語ってのは基本的にオナニーだからだろ。
609 名前：デフォルトの名無しさん mailto:sage [04/08/25 09:26]: プログラミング言語といっても、わかり易い言語にする為には自然言語的なセンスが
必要だとは思う。かといって Smalltalk みたいに英語に近くするとネイティブ以外に
分かり辛い所も。
610 名前：デフォルトの名無しさん mailto:sage [04/08/25 12:00]: >>605
ってかRubyはクラスベースじゃないの？SeRubyのこと？

漏れはある程度記号が使われるコードのほうがいいなぁ。JavaやPythonとかだと記号が少ないと感じる。
611 名前：1 mailto:sage [04/08/27 22:02]: >>599
おお、言語作ってますか。いいですねぇ。
ちょっと今時間的余裕ないのですが、
そのうち触らせてもらいます。
開発頑張ってください。
612 名前：デフォルトの名無しさん mailto:sage [04/08/28 22:46]: Ruby知ってると幸せになれるよ

JavaScript程ではないけど
613 名前：デフォルトの名無しさん mailto:sage [04/08/29 07:45]: 宣伝乙。
このｽﾚに Ruby 知らないﾔﾂは居ないと思うが。
614 名前：デフォルトの名無しさん mailto:sage [04/08/29 18:19]: >>613
ﾉｼ

名前を知ってはいるけど見たこと無い
使わないし
615 名前：デフォルトの名無しさん mailto:sage [04/08/30 00:47]: 今日日うっかりデフォインスコとかすると/usr/binあたりに居ないか？＞Ruby
てかWinとかだと自前で入れないと入らんか
616 名前：デフォルトの名無しさん mailto:sage [04/08/30 05:46]: Rubyはそろそろ廃れてきたからね
やっぱどこでも使えるJavaScriptがいいよ
617 名前：デフォルトの名無しさん [04/10/25 17:38:23]: Selfの論文翻訳されてるよage
ttp://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html
618 名前：デフォルトの名無しさん mailto:sage [04/10/25 18:44:46]: traits使って説明しだした辺りからうさん臭さを感じた
619 名前：デフォルトの名無しさん mailto:sage [04/10/25 20:48:59]: >>618
具体的にはどんなふうに？
620 名前：デフォルトの名無しさん mailto:sage [04/11/05 23:16:06]: 相変わらず人いないね
621 名前：デフォルトの名無しさん mailto:sage [04/11/06 01:14:41]: >>618
今までずっと「tetris使って説明しだした辺りからうさん臭さを感じた」と読んでた。
622 名前：デフォルトの名無しさん mailto:sage [04/11/06 01:19:24]: >>620
つーか、最初から2-3人で回し書きしてるのがミエミエだったろ(藁
プロトタイプ最強君と、クラスベースも等価君と、バランス君。
623 名前：デフォルトの名無しさん mailto:sage [04/11/06 03:45:34]: 各自が俺言語を持ち寄って自慢するスレでもいいんじゃね？
624 名前：1 mailto:sage [04/11/14 18:36:14]: >>622
>>620は「相変わらず」と言ってるので「つーか」になってないよー
625 名前：デフォルトの名無しさん [04/12/18 01:53:39]: これがプロトタイプベースだぜ。クラス厨共、どうだよこのクールさは、ああん？

みたいなコードキボン。
626 名前：デフォルトの名無しさん mailto:sage [04/12/18 03:08:12]: >>625
言語システムのローレベルをくみ上げていく（っと言うかブートストラップと言うか）の段階が一番興味深い結果出すと思うが。
627 名前：デフォルトの名無しさん [04/12/18 03:17:45]: >>626
どんな感じ？イメージ沸かぬ。
628 名前：デフォルトの名無しさん mailto:sage [04/12/18 03:23:45]: >>627
クラス型の言語だとObjectがすべての原型->そのObjectのClassのメタクラスの->Object
みたいな循環部分を最初にどうやってくみ上げるかってお話があるじゃないですか。
プロトタイプ型言語だと自分を派生させる機構は最初何から始めるのだろうって当たりが面白いんじゃないのって事なんで
あんまり深く考えてたわけじゃないです。

小生４年くらい前にpureオブジェクト指向言語をclassベースでやったときにその基底部分のくみ上げが非常に面白かったんで
同じようにプロトタイプ型言語でも興味深い（言語の性格に依存した）立ち上げ方法があるんでないのかって事です。
629 名前：デフォルトの名無しさん mailto:sage [04/12/18 06:53:50]: 俺も幼稚園ぐらい前に関数型言語をクロージャべースでやってたなあ
630 名前：デフォルトの名無しさん mailto:sage [04/12/18 09:03:34]: ごめん、俺も小学4年生くらい前に、って読んだw
631 名前：デフォルトの名無しさん mailto:sage [04/12/18 11:45:03]: Objectクラスに相当するモノは、
プロトタイプではいかにあるべきか考えるのが面白いって事？
632 名前：デフォルトの名無しさん mailto:sage [04/12/18 19:24:45]: >>628
俺は、ある言語が扱う範囲を１つの世界と見立てると、基幹の定義はその世界の外に作っちまうな
あたかも“初めから存在してました。深くは考えないでください”って感じに
633 名前：デフォルトの名無しさん mailto:sage [04/12/18 19:42:19]: どうやっても遅い
↓
誰も使いたがらない
↓
死滅

このプロセスで大筋間違いないよね
634 名前：デフォルトの名無しさん mailto:sage [04/12/18 20:10:22]: >>633
ははは君の理論で行くと全ての言語が一度に滅ぶでないかw
完全にカスタマイズできるマシン語が最強なのだよ、ってな感じにね

あふぉかと
635 名前：Aransk [04/12/19 16:53:31]: １．敢えて遅くしてまで言語に不自由さを生み出している。
２．不自由だから誰が使っても大差ない。
３．誰でも使い出す。
ってのはどうなんでしょう？
デザインパターンにしても一握りのチョンの
後をポチが追いかけるスタイルですよね。
自由にすると大多数のポチは何をしたら良いのか
さえ分からないから、言語は自由度を制限せざる得ない。
ただ問題はワタクシのように単なるポチの
くせにチョンを真似て自由な言語を好むタイプが
存在するから話がややこしくなる。
（我流で無茶苦茶書くから…書いても一応動くから…
本人でもメンテ出来ないコードを誰がメンテできるのか…）
これが大規模開発にチョン言語が使えない理由では
ないでしょうか？
636 名前：デフォルトの名無しさん mailto:sage [04/12/19 19:58:02]: >>635
他人の指向にどうこう言う筋合いは無いし、事実御前の考えも一理あるが、
少なくともデザパタに関しては認識そのものが間違ってる
よく勉強しなおす事
637 名前：Aransk [04/12/20 10:17:58]: >>636
デザインパターンを示されても理解が困難な
ポチにパターン自体を創造出来るかどうか？
これを問題にしておるのであります。
チョンが道筋をつけその後、ポチの程度に
よって追いかけかたが変わります。
新たなデザパタを作れるポチも居れば
利用するだけのただ乗りポチも居る。
一生オブジェクト指向に縁無きポチも存在する。
但し理解して利用しないのと、理解出来ずに
利用できないのとでは雲泥の差がある。
理解して利用しないのは十分チョンの
見識有りと考えます。チョンを超えている
可能性も否定できません。
638 名前：デフォルトの名無しさん [04/12/21 02:16:30]: >>616
>やっぱどこでも使えるJavaScriptがいいよ
JavaScriptってもうプロトタイプベースじゃないんじゃない？
639 名前：デフォルトの名無しさん mailto:sage [04/12/21 10:34:43]: クラスが付いたから？　ｗ

ちなみに「クラスがない」ってよく言われるけどありゃ嘘で、
本当は「クラスを言語が用意する必要がない」（つまり、
他の基本的言語機能で必要なら実現可能）ってだけの話です。

実際、SELF にも NewtonScript にもクラス（SELF では
トレイトと呼ばれているけど）はあって、言語仕様では
重要な役割を演じています。
640 名前：デフォルトの名無しさん mailto:sage [04/12/21 10:47:25]: REBOL(www.rebol.com/)
変数のスコープと評価順序に癖のある言語ですが、プロトタイプベースらしいので。

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
641 名前：デフォルトの名無しさん mailto:sage [04/12/21 10:47:41]: プロトタイプベース（この呼び名は語弊があるから避けるべきで、
インスタンスベースとか、オブジェクトベースのほうが良い
と思います）の要件は「インスタンスがメソッド（メンバ関数）
や属性を *クラスに依存せずに* 持てること」に尽きるでしょう。
642 名前：デフォルトの名無しさん mailto:sage [04/12/21 10:49:12]: >>640の実行結果
GATU GATU
WAN! WAN!
GATU GATU
WAN! WAN!
NIAO NIAO
WAN! WAN!
GATU GATU
PAKU PAKU

: は代入宣言, / メンバの参照。
does は、引数なし関数を生成する関数。makeは、newとかclone相当。

>>590
REBOLでは影響なし。Prothonでは影響がありました。
643 名前：Aransk [04/12/21 18:19:04]: >>641
>プロトタイプベース・オブジェクト指向とは
>sumim.no-ip.com:8080/wiki/493
によれば
>「インスタンスがメソッド（メンバ関数）
>や属性を *クラスに依存せずに* 持てること」
ではなく、問題は本来持てないはずが持ててしまう
ことにあるのではないでしょうか？
インスタンスは持てちゃ駄目なんです。
退歩を進歩と錯覚しているに過ぎない。
Rubyに特異メソッドを持てなく
することや、カプセル化を厳しくしろ
って言うほうが逆に大変なんじゃなか
ろうか。
ルーズ化するほうがイージーだってこと
もある。
644 名前：デフォルトの名無しさん mailto:sage [04/12/21 18:32:15]: >>643
つまり
・ ECMAScript や JavaScript は問題だから使うべきではない。
・ DHTML で使う際にも、<input onClick="hoge()"> なんて書けちゃダメで、ちゃんとクラス化して
　class HogeButton { onClick() { hoge();} }; <input class="HogeButton"> 等と記述できなくてはおかしい
ということですね。

同意しておきます（ｗ
645 名前：デフォルトの名無しさん mailto:sage [04/12/21 18:34:17]: Rubyから特異メソッドをなくすにはコードを削りはするが追加する必要はないとだけいっとく。
646 名前：デフォルトの名無しさん mailto:sage [04/12/21 19:41:07]: >>643
>>「インスタンスがメソッド（メンバ関数）
>>や属性を *クラスに依存せずに* 持てること」
>ではなく、問題は本来持てないはずが持ててしまう
>ことにあるのではないでしょうか？
>インスタンスは持てちゃ駄目なんです。

関数/メソッド自身もオブジェクトな言語では、
関数を変数やフィールドにいれたりする事は自然な事なのですが。
647 名前：デフォルトの名無しさん mailto:sage [04/12/21 22:24:36]: クラスを「ユーザー定義可能な型」として代用する“クラス指向”オブジェクト指向
においてはインスタンスはクラス（すなわち、それが属する型）の支配下にあって
しかるべきだし、各々が独自の関数（インターフェイス）を持つなどということは言う
までもなく、クラスをしても動作中に仕様を換えるなどということはあってはならない
こと。したがって、インスタンスベース（と、それにより実現されるメリット）なんて、
とんでもない…ということになる。

ところが、ケイの“メッセージ指向”オブジェクト指向の世界では、考え方がかな
り違う。オブジェクトはソフトウエアを構成する一部ではあるが、それ単独では
非力で意味のない部品であってはならない。それぞれが独立して機能する
小さなコンピュータであるべきだと彼は言う。＊１　これらが高速のネットワーク
で接続され、ソフトウエアは機能する。彼の設計したSmalltalkでは（残念ながら
クラスベースで、インスタンスはその支配下にあるが、それでも）クラスもまた
オブジェクト、つまり、別のクラス（メタクラス）のインスタンスであることや、動作
を止めずにクラス定義の変更を通じてオブジェクトの振る舞いを変えられること
などに彼のオブジェクト指向が目指していたところの片鱗を見ることができる。＊２
もちろんこれは、前者の立場の者、有名なところではメイヤー、の目には、
いたずらに混乱を招くだけの、無用の（あるいは代替可能な）仕様にしか見えない。＊３

このように、オブジェクトが自らの振る舞いをクラスに依存せずに決められることについて
の評価は、よりどころとするオブジェクト指向が、クラス指向なのか、メッセージ指向なの
かによって違ってくる。インスタンスが“本来”どうあるべきか、もしかり。

＊１　www.akademia.co.jp/Smalltalk/SML/archives/SRA.archives/2003-October/006339.html
＊２　ただし、ケイはインスタンスベースに対する態度を保留している。
＊３　「オブジェクト指向入門」 ISBN: 4-7561-0050-3
648 名前：デフォルトの名無しさん mailto:sage [04/12/21 23:11:02]: >>647
> ＊２　ただし、ケイはインスタンスベースに対する態度を保留している。

LISP的でカオティックすぎると批判していなかったか？
649 名前：デフォルトの名無しさん mailto:sage [04/12/21 23:35:56]: >>648
よければ出典を。　まあ、いかにもらしくて言いそうなことだけれど。ｗ
念のため、保留との解釈の根拠はこちら。

www.google.co.jp/search?q=cache:WbjukQKKfwAJ:glab.cs.uni-magdeburg.de/
~croquet/downloads/Croquet0.1.pdf
650 名前：デフォルトの名無しさん mailto:sage [04/12/21 23:44:54]: Smalltalk流にパーシスタント・オブジェクトの集合してシステムが出来上がってるものの場合、
クラス（←これもまた何かのインスタンス）を動的に変更できない方が不自然な感じがする。
Lispで何でも再定義できるのも同様。

システム全体がとてもステートフルなものになってしまうという問題は確かに大きいのだけれど、
dll hell等でどうせシステムはとてもカオティっクでステートフルになるんだから別にいいか。

いや、そんなことないか。如何様にも変更可能なクラス（インスタンス）はいいとして、何か不動の
インタフェイス的なものが無いとやっぱり辛いな・・・
651 名前：デフォルトの名無しさん [04/12/22 02:11:15]: staticなモデル化が容易で型チェックでその整合性が保証される
Javaとかの「普通」のクラスベースOO言語に対して、プロトタイプベースってどの辺にメリットがあるのかな。
便利な場合もあるだろうけど、ただ便利じゃなくてせめてそれがクールに感じられるコーディングにならないと
言語としてメリットとは言い難い気がする。
652 名前：デフォルトの名無しさん mailto:sage [04/12/22 02:19:44]: >>651
委譲を使うコードがむちゃくちゃシンプルになる。

ttp://homepage.mac.com/mkino2/oop/chainOfResp/
653 名前：デフォルトの名無しさん mailto:sage [04/12/22 04:15:44]: >>650
> Smalltalk流にパーシスタント・オブジェクトの集合してシステムが出来上がってるものの場合、
> クラス（←これもまた何かのインスタンス）を動的に変更できない方が不自然な感じがする。

それで実際、クラスどころかオブジェクトのサイズから属性やメソッドまで動的に
変更できるわけです。
654 名前：デフォルトの名無しさん mailto:sage [04/12/22 05:59:54]: プロトタイプベース言語のミニマルセットの定義ってどこかに無いですか？
できれば書籍が一番うれしいのですが。

googleじゃ引っかからなかった（英語圏は試してない）
655 名前：デフォルトの名無しさん mailto:sage [04/12/22 11:28:30]: >>654
ミニマルではないけれど、インスタンスベースを語る前に、少なくとも
これだけには目を通しておくべきかと思います。

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

がそれなりにページを割いていて、比較的詳しいです。これを読むと
クラスベースとプロトタイプベースに本質的な違いはなにもないことも
分かります。
656 名前：デフォルトの名無しさん mailto:sage [04/12/22 12:49:57]: SELF に関しては、メッセージ送信重視の立場と、インスタンスベースの
立場を分けて評価する必要があります。たとえば、インスタンス変数を
持たず、スロットを振る舞いと属性で共有することについては、名前の
衝突の問題が生じることがすでに分かっています。（つまり、スロット
アクセスを多態させるときに getXXX などと別名を設けないといけない）
こうした問題はメッセージ送信重視の立場から来るもので、インスタンス
ベースであることとは関係ありません。

SELF はメッセージ指向寄りの（しかしメッセージ指向とは違う、単に
メッセージ送信重視の）立場から、Smalltalk の実装に対して生じた
疑問、あるいは想定しうる理想像を具現化して見せたものとみることが
できます。その結果生じたもののひとつがインスタンスベースだと
考えておくのが無難です。つまり、インスタンスベースの特徴は SELF
に見ることができますが、SELF の特徴すべてがインスタンスベースに
当てはまるわけではないということです。

インスタンスベースの他に、SELF の副産物としては、コスト高で最適化
が難しいメッセージ送信の行きすぎた(笑)徹底により、VM の高速化技術
が生まれたことが挙げられます。これは Strongtalk という静的型チェック
機構を持つ Smalltalk の派生物を経て、現在、Java VM に役立てられて
います。
657 名前：デフォルトの名無しさん mailto:sage [04/12/22 14:06:15]: >>656
> getXXX などと別名を設けないといけない

スミマセン。これ嘘です。getter ではなく setter のしかも、SELF では
なく Io の言語仕様上の問題を思い違いしておりました。忘れてください。
658 名前：Aransk [04/12/22 19:01:04]: 例えばこんなパースペクティブもありかなと
考えていること：
言語論的に申し上げればフィンランド語は動詞の変化
だけでも30型あります。ヨーロッパ系言語のなかでは
最も複雑な文法体系を有しております。
ご承知の通りフィンランドの教育水準の高さは世界の
他の国を圧倒しております。つまり使いこなせれば
言語は精緻であればあるほど頭脳を進化させます。
コミュニケーションの幅が広がる次第です。
西サモア諸島の言語は現在形しかありません。
プログラミング言語と同じです。
従ってプログラマーの頭脳水準は…。
なんてことを言いたい訳ではありません。
つまり精密なルールは文明の進化に負っております。

で、話をインスタンスにメソッドやフィールドを
持たせることに戻ります。
クラス概念の精緻化というパースペクティブから解釈
するとそれは単にルールを破っていることに過ぎない。
また、LispやSchemeの言語文法自体を変化させる
マクロは言語自体を破壊することになる。
これは不自由で精緻なルールがあるから
人間の頭脳は進化するというパースペクティブから
の意見です。
659 名前：デフォルトの名無しさん mailto:sage [04/12/22 19:32:17]: >>656
Programming as an Experience: The Inspiration for Self
にも出てくるけれど、
「スロットで振る舞いと属性を共有する」
つまり
「スロットの中身が値ならそれを返して、
メソッドオブジェクトならそれを実行する」
というやりかただと、
メソッドオブジェクトを値としてほしい場合に困るっていう問題があります。
これに対してSelfではmirrorオブジェクトというのを使うみたいです。
660 名前：デフォルトの名無しさん mailto:sage [04/12/22 22:24:18]: >>655
おお。SELFってこういう物だったんだ。参考になるなあ。
661 名前：デフォルトの名無しさん [04/12/23 03:08:03]: >>652
CoRなんてごくたまに使う程度のモンじゃない？
LispのLambda式みたいに、CoRベースの世界が構築できるなら別だけど、
クラスベースOO言語とくに静的型付の普通の言語のメリットには遠く及ばないよね。
662 名前：デフォルトの名無しさん mailto:sage [04/12/23 04:21:44]: つまり和訳すると、委譲がすっげーシンプルに書けるのを見て
ちょっとびっくりしちゃったわけね…。
663 名前：デフォルトの名無しさん mailto:sage [04/12/23 12:29:21]: クラスベースでならメタ・プログラミングが必要な場面で、
現状のクラス・ベースでは、そういった場面をデザインパターンや
クラス・システムの拡張で対応しているが、(そのシステム数だけ、それを特徴とした新たな言語を生み出している)

プロトタイプでは一般的な概念の枠内で拡張し対応できる。
例として、AOP拡張とかプロトタイプ・ベースの言語で提示してみるのはどうでしょう?

例えばJAVAがソース or バイトコード変換といった手段で実現している事を、
プロトタイプ・ベースでどれだけ簡単に出来るかというのを比較してみると面白いかもしれません。
664 名前：デフォルトの名無しさん mailto:sage [04/12/23 12:37:48]: >>663
classがfirst class objectであるかどうかの問題とゴッチャになってないかい？
665 名前：デフォルトの名無しさん mailto:sage [04/12/23 12:47:50]: 漏れはそういったハードコアな分野ではクラスベースとの差異はあまり無いと思ってる。憶測だけど。
とはいえAOP関連だと、特定のインスタンスのみにコード挿入するとか、クラスベースでは出来ない
ものも簡単にできるのも確か。

でも、さんざ既出のDHTMLのようなものが簡単に書けるというのがプロトタイプ言語の特徴だと思う。
クラスを沢山作らなくても、複数のimgタグでonClickの動作を変えられるし。.NetのSystem.Windows.
Forms以下の各種コントロールにイベントハンドラを記述するというアーキテクチャなんかも、これは
prototype言語の守備範囲なんじゃないか？とか思うし。
666 名前：Aransk [04/12/23 15:45:54]: C < Pascal
>C++ < Java
>CommonLisp < Scheme
>Smalltalk < Self
>と思うわけですよ．この気持わかるでしょ？
その気持ちはすっごく分かる。
幼稚園時代だけど。W

不思議と実用性は前者が高いんですよね？
C++とJavaのケースを除き…というか
本来の意味の実用性で言えば個人的には
C++とは思いますが。
理由として考えられるのは
アカデミックな理論整合性より現実の
ソリューションは複雑であるということが
一つ。
もう一つはプログラマーの専門性の問題です。
誰でもとっつき易いものでは食えない
が、しかし、あまりに少数しか分からないもの
でも職業として成立しない。
このパースペクティブから、プロトタイプ言語の
自由度は協業度の面でマイナスとして
作用しないのでしょうか。
つまり作った奴しか分からないというか
作った本人もどのインスタンスに細工したのか
忘れてしまうとか。
667 名前：デフォルトの名無しさん [04/12/23 23:31:59]: >>664
ごっちゃ通貨、それは包含関係にあるのでは？
何か問題が？
668 名前：デフォルトの名無しさん mailto:sage [04/12/24 01:54:13]: >>667
クラスをfirst class objectとしているクラスベース言語が多数ある以上、
>>663は完全にトンチンカンなわけだが。
669 名前：663 mailto:sage [04/12/24 08:40:35]: AOPって例がまずかったかな?

first class objectって時点で、
多くのプロトタイプ(インスタンス)ベースの実装と本質的には同じものになるだろうけど。
クラスやオブジェクトの拡張がクラス・ベースの概念の枠内でどのように扱われているかという点において、

クラス・ベースの言語ではメタ・プログラミングが必要な場面で、
プロトタイプ(インスタンス)・ベースでは自然に備わっている特徴で解決出来る。といった主張でした。
670 名前：Aransk [04/12/24 10:41:39]: 常に物事は批判的に検証するなかでしか
重みや深みは付加されません。
敢えてプロトタイプベースの命綱でなる
オブジェクトに対するメッセージパスについて
伺いたい。
本質的な機能として引数を指定して関数を
呼び出すこととの差異はなんでしょうか？
つまり敢えて擬人化した名前を付することに
よる効果の方が実質を上回っていないの
でしょうか。
671 名前：デフォルトの名無しさん mailto:sage [04/12/24 13:16:06]: >>669
>クラス・ベースの言語ではメタ・プログラミングが必要な場面で、
>プロトタイプ(インスタンス)・ベースでは自然に備わっている特徴で解決出来る。といった主張でした。

例示してください。
672 名前：Aransk [04/12/24 18:07:28]: >sumim.no-ip.com:8080/wiki/493
リンクを外しておられませんでしょうか？
673 名前：1 mailto:sage [04/12/25 21:11:44]: >>Aransk

>インスタンスは持てちゃ駄目なんです。
なんで？
駄目な理由を述べよ。

>誰でもとっつき易いものでは食えない
これ、クラスベースに対するプロトタイプベースのルールの少なさに対して言ってるんだよね。
バッドノウハウでしか食ってけないプログラマなんていらないよ。

このスレもいつの間にか1年経ちましたねぇ。
674 名前：Aransk [04/12/26 17:30:24]: １．ご承知の通りクラスとインスタンス概念の導入は
型生成と実動プログラムを分離したところにある訳です。
従ってインスタンスが自ら変形して新たなインスタンスを
生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような
倒錯した状況を生み出すことになるのです。
２．従ってプロトタイプベース言語は愛玩用のToyProgramを
作成することにその長所を発揮すべきではないでしょうか。
成熟社会はますます個人の自由な暇潰しを求めます。
そのニーズにぴったり合致した言語ではないでしょうか。
と、まぁ敢えて批判的に申せばこうなります。

ところで１っつぁん、>>670に対する
貴方ご回答を期待しておるのですが？
675 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:35:31]: >>674
クラスベースはオブジェクト指向の誕生と同時に誕生したと思っていたが

考え方が根本的に違う

プロトタイプベースの利点は、既存のオブジェクトを（ある程度まで）自由に弄れる事
例えば、HTML で記述された既に画面上に存在するボタンなどに追加の挙動を割り当てられる等
クラスベースだと、予め全てのボタンを定義しておかなければいけないという制約が付く

オブジェクトを変更させない方に特化するか、変更させる事に特化させるか
どちらも同様にニーズがあることは自明で、どちらが優れているかは議論すべきじゃない

と俺は思う

……というか、クラスベースとプロトタイプベースのどちらが優れているかなんて
日本語と英語のどちらが優れているかを議論するようなもんだろ？
676 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:36:00]: >>674
というか、>>670 の『擬人化』の意味が良くわからんとですが
677 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:54:22]: >>675
日本語の方が優れています。
これは全世界で一致している見解です。

と言ったら？
678 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:56:17]: 現存アプリ数を考えればクラスベースが優れていることが明白なんだが。
679 名前：デフォルトの名無しさん [04/12/26 19:06:29]: Ｒｕｂｙ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ｐｕｒｏｔｏｔａｉｐｕ
680 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:20:43]: >>678
すごいなぁ
幾ら優れている言語が出来ても、初めのうちは糞言語ですか
681 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:25:32]: >>678
考えることをしなくなった人間ってのはもうおしまいかと。
682 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:30:31]: Ｒｕｂｙ以外は必要ない。
683 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:35:40]: >678
それいったら「構造化サイコー」になっちまうが……
いくつのプログラムがCで書かれていると思っているのかね？
PerlやPHPみたいな「ちょっとオブジェクト指向」もたくさんあるし
684 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:49:08]: ＞いくつのプログラムがCで書かれていると思っているのかね？

やたらと。それがなにか？
685 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:49:55]: >>683

OOPLとOOを混同しちゃだめだよ。
686 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:52:03]: どれだけのスクリプトがRubyでかかれているかしっているかね？
687 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:53:37]: >>686
数えるほどしかないよ
不可能な数じゃない
がんばれｗ
688 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:55:22]: プロトタイプベースだとウィルスとか簡単に作れるね

proto
↓
object

を

proto
↓
ウィルス
↓
object

にするだけで全体感染する
689 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:55:40]: >674
>インスタンスが自ら変形して新たなインスタンスを生成することは
インスタンスが「勝手に」変わるわけじゃねえって。
プログラマがインスタンスを加工して目的のインスタンスに
近づけているんじゃねえかよ。

>鯛焼きの鯛が金型無しで鯛焼きを作るような
はあ、型や設計図が無いとモノを作れないのかな？Aranskは。
プログラマは鯛焼きだけ作れりゃいい、つうわけでもないだろうに

鯛焼きの金型じゃ、お好み焼きは作れんわ

>２．従ってプロトタイプベース言語は愛玩用のToyProgramを

あと、
・アイディアを検証するための「実験プログラム」
・実際に動かしながらプログラムを作成する「成長プログラム」
なんかも、柔軟性と即効性を考えるとちょうどいいかもねぇ
まあ、職人＆日曜大工向けのツールだわな。
コーダーには触らせたく無いねぇ
690 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:56:17]: 先輩はルビヲタです。
wでvi *.rbとかやってるとああ、どっかではたらいてんだなと。
691 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:56:52]: Ruby!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
692 名前：デフォルトの名無しさん mailto:sage [04/12/26 19:57:01]: >688
どうやってプロセスに潜り込むの？
693 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:05:17]: >>692
実際Smalltalkみたいな環境だと簡単にできる
694 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:08:10]: >>688
ばーか

superclass
↓
ウィルス
↓
subclass

にするだけで全体感染しますよ
695 名前：692 mailto:sage [04/12/26 20:10:31]: >693
Smalltalkはクラスベースでつな。
クラスベースもプロトタイプベースも関係ないような……
696 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:18:21]: > 従ってインスタンスが自ら変形して新たなインスタンスを
> 生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような
> 倒錯した状況を生み出すことになるのです。

考え方がクラスに縛られてますね。
クラス・ベースで考えるならこの場合はfactoryパターンを参考にするといいと思います。

プロトタイプベースで言い直すなら、鯛焼きの *インスタンスに当たるもの* はその鯛焼きの複製です。
金型のインスタンスが鯛焼というのはクラスベースの概念で解釈した場合で、
プロトタイプの世界では、タイヤキとその金型はそれぞれ独立したオブジェクトであり、
金型の複製が鯛焼になるという事はありません。

インスタンスという概念自体がclassベースのものである事に注意して下さい。
つまり、誤解の原因はインスタンスだと思っていたそれが、プロトタイプの世界ではインスタンスではなく複製である事。
オブジェクトが存在するためにクラスといった概念を必要としていない為、
インスタンス生成といった作業自体が必要ないのです。

敢えて、このクラスやインスタンスという概念をプロトタイプ・ベースに導入するなら、
金型オブジェクトに鯛焼オブジェクトの複製を生成するようなメソッドを持たせるとわかりやすくなると思います。
この場合でも、金型はクラスといった概念ではなく、金型自身が具象化したオブジェクトであり、
金型にも細工を施し、別の形のたいやきを生成したりする事が出来ます。

クラスを、オブジェクトの定義宣言みたいに考えると、
定義がころころ変わったり、鯛焼がある日突然卵焼になってしまうと困るといった主張は理解できます。
が、これはクラスベースで思考しているからであって、プロトタイプ・ベースでは、
金型が変わったからといって、すでに作られた鯛焼まで変わってしまうとは限らないのです。

ところで、擬人化して語ると、複製を作るといった作業が身近な例に当てはまらないので、
メタファを作るのは難しいかも知れませんね。
コンピュータ上の概念で説明するなら、データのコピーで済ませられるのだけど。
697 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:42:56]: 話がプロトタイプの根幹について流れているのを途中で止めてしまうんで荒れちゃうかもしれんが。

プロトタイプベース言語のメッセージパッシング時の最適化に関する論文とか資料へのポインタをご存じの方がいたら示唆お願いしますです。
NewtonScriptもどき作ってるんですけど_Parentの_Parentの………とセレクタ追いかけ回すのめちゃくちゃ重くないですか？
698 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:47:54]: >>697
問題ない。俺が作ったときは proto を追尾しなかったw
最終的に clone 時にスロット全部コピーしたからなぁ

まあ、俺も知りたいところではあるが
699 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:58:15]: >697
そこはオレも悩んでいるんだけど、やっぱりキャッシュするしか無いかな……

freeze - thawを導入して、protoの変更タイミングを通知するようにするか、
protoが変更されると全てのキャッシュが無効化されるようにするか……
700 名前：デフォルトの名無しさん mailto:sage [04/12/26 21:09:50]: >>697
Selfの論文が山程ある。
701 名前：デフォルトの名無しさん mailto:sage [04/12/27 14:53:52]: >>697
ttp://research.sun.com/self/papers/papers.html
のImplementationに関する論文でしょう(読んでないので違ってるかもしれない)。
Type inferenceについての論文も関係あるかも。
702 名前：697 mailto:sage [04/12/27 15:58:45]: SELFのはSunのサイトに標題一覧があるのですが（701さんサンクス)ACM会員じゃないからなぁ。
大学に聴講生制度あったはずだから登録して図書館で探すしかないのかorz

ACMの論文集って普通の図書館でも取り寄せ効きますか？
703 名前：デフォルトの名無しさん mailto:sage [04/12/27 16:02:10]: PSとれるでしょ?
704 名前：Aransk [04/12/27 17:03:03]: ttp://sumim.no-ip.com:8080/wiki/493 より引用：
>実はプロトタイプベースは、クラスベースと相反するものでは
>なく、クラスベースより一段階プリミティブなものだと
>考えると、つまり、プロトタイプベースにいろいろな機構
>（トレイトとしてクラス）や制約（独自メソッドの追加や
>再定義、インスタンス変数の追加を禁じる）を設けることに
>よってできたのがクラスベースだと解釈すれば何ら問題が
>ないことが分かりました。
これって卓見だと思う訳ですよ。
優劣の問題ではなく、クラスベースってプロトタイプ
ベースより進化した形態なんだと思う。
つまりコピー機能（型生成）と実プログラム機能を分離する
ことでより構造化されたプログラミングパラダイムを
生み出した訳です。つまりある自由度、（古くはgoto文）などを
規制することでより間違いの少ない安全度の高いプログラミング
レベルを目指してきました。
個人的になんでも出来ることと、協調してプログラミング作業を
する場合とは違うということです。
さらに出来ることと出来ないこととは違います。
必ずしも前者が後者をスパーシードしているとは言えないのです。

擬人化とは：
例えばメッセージパッシングってオブジェクトが
オブジェクトにメッセージを送っているようなイメージが
あります。しかしCの関数呼び出し、やCobolのサブルーチン
の呼び出しと実態機能的にそう変化はないのではない
でしょうか。
つまり単なる名前だけによるプログラミング機能のラッパー的
要素が含まれているように思えるが…。
705 名前：デフォルトの名無しさん mailto:sage [04/12/27 18:19:40]: >>702
大部分の論文はciteseerその他からpdf版も手に入るみたいです。
706 名前：デフォルトの名無しさん mailto:sage [04/12/27 18:38:28]: >>704
> さらに出来ることと出来ないこととは違います。

ここが藁い所なのか？
707 名前：デフォルトの名無しさん mailto:sage [04/12/27 19:16:09]: メッセージパッシングっていうのは別にプロトタイプ言語固有の用語ではなくって、
ごく一般的な言葉だと思う。
もちろん本質的ではないし、このスレでも使っているのは１名のみに見える。

あと
＞必ずしも前者が後者をスパーシードしているとは言えないのです
これは誰しも同意するだろうけれども、何かを含意していないと無意味な主張。
で含意している内容が「クラスベースってプロトタイプベースより進化した形態なんだと思う」
ならば、「そうですか」としか言い様がない。確かにDHTMLの保守性は悪い。

爬虫類は両生類より進化している、という主張は可能だろうけれども、
サンショウウオ本人やサンショウウオ飼育者にとって、その主張に何か意味があるか、
というとかなり疑問。鳥は恐竜よりも進化している？でも鳥よりも恐竜の方がずっとクールでカッコイイよ。
708 名前：1 mailto:sage [04/12/27 21:15:22]: >>Aransk
>>670
> 本質的な機能として引数を指定して関数を
> 呼び出すこととの差異はなんでしょうか？
> つまり敢えて擬人化した名前を付することに
> よる効果の方が実質を上回っていないの
> でしょうか。

どうもメッセージ送信と関数呼び出しの違いを
気にしているようですが、それとプロトタイプベースとの関係がわかりません。
メッセージ送信モデルと関数呼び出しモデルの一番重要な違いは
受け手であるプログラマの解釈である私は思います。
中でやってることは同じ場合が多いことはあなたも知っているかと。

あなたの言う「本質的」や「実質」が何を指しているのかがわからないので、
うまく答えられてないですね。すみません。

>>674
> １．ご承知の通りクラスとインスタンス概念の導入は
> 型生成と実動プログラムを分離したところにある訳です。
> 従ってインスタンスが自ら変形して新たなインスタンスを
> 生成することは、鯛焼きの鯛が金型無しで鯛焼きを作るような
> 倒錯した状況を生み出すことになるのです。

倒錯した状況ねぇ…それがインスタンスはメソッドを持てちゃ駄目の答えですか。
それはつまり世の中のほとんどのプログラムがクラスベースで書かれているから
という答えと変わらないんじゃないですか？
何故それが「倒錯」と言えるのかを示さない限り。
クラスベース的な鯛焼きのメタファをプロトタイプベースに当てはめてみて
こいつはおかしい! と自信たっぷりに言われましてもどう対応していいやら…
709 名前：689 mailto:sage [04/12/28 02:35:50]: >優劣の問題ではなく、クラスベースってプロトタイプ
>ベースより進化した形態なんだと思う。

進化<->退化という同一ベクトルにある話じゃないと思うんだけどね

自分だけだろうけど、

プロトタイプベース
　「全てを持つ」要素を組み上げてシステムを構築
　->細胞的、生体組織的
　　柔軟な、増殖的

クラスベース
　全てを記した図面から要素・組織・システムを作り出す
　->機械的、人工物的
　　効率的、最適な

といったイメージがあるなあ
710 名前：デフォルトの名無しさん mailto:sage [04/12/28 07:28:23]: とりあえずAranskは>>90-206や>>239-276および>>362を読め。
711 名前：デフォルトの名無しさん mailto:sage [04/12/28 11:59:39]: >>709
>進化<->退化という同一ベクトルにある話じゃないと思うんだけどね
特殊化と言うんだと思う。

ある差異を「特殊化」というか「進化」というかは、純粋に発言者の観点の違いでしかないのだけれども。
すぐ死んでしまう脊椎動物は原生動物よりも進化していると言えるのか、とか、
ウイルスは（その方向はラディカルだけれども）途轍もなく進化した究極の生命形態じゃないのか、とか。

後段のイメージの方だけれども、Smalltalkはそれなりに柔軟で増殖的だと思う。C++ も。Javaは（ｗ
漏れはたぶんSmalltalkについてはVM全体で一つの「インスタンス」とイメージしてるっぽい。
既存のクラスも勝手にガチャガチャ変えるから。
712 名前：Aransk [04/12/28 14:17:21]: >一番重要な違いは受け手であるプログラマの解釈である私は思います。
>> さらに出来ることと出来ないこととは違います。
>ここが藁い所なのか？
プログラマの解釈性に甘えて言葉だけが実体以上に
イメージを増大させていないでしょうか？
というのが論点の一つです。
例えばRubyで継承したクラスから上位クラスの
Privateメンバーにアクセス「出来ない」ようにする
ことは「出来ない」のではないでしょうか。
それが欠点ではなく売りになることがおかしい
と考えるのです。
またPerlでThere is not more than one way to do it.
という売りがありますが、単に言語仕様の輻輳に過ぎない
とも言えます。
プロトタイプベース言語に敢えて批判的な立場で
意見を申し上げておりますが…ってゆうか
これまでの２ちゃんねるの発言では全てその
スタンスを保つようにしております。
メリットの影にあるデメリットにも
光を当てて総合的、多面的な評価こそ
望ましいと考えるからであります。
713 名前：Aransk [04/12/28 14:18:21]: ところで、
>実はプロトタイプベースは、クラスベースと相反するものでは
>なく、クラスベースより一段階プリミティブなものだと
>考えると、つまり、プロトタイプベースにいろいろな機構
>（トレイトとしてクラス）や制約（独自メソッドの追加や
>再定義、インスタンス変数の追加を禁じる）を設けることに
>よってできたのがクラスベースだと解釈すれば何ら問題が
>ないことが分かりました。
この卓見を書いた人はもうこのスレには
参加してないのでしょうか？
是非ご意見を頂きたい。
714 名前：697 mailto:sage [04/12/28 14:23:40]: >>703,705
はい、落としてきました（ACMにjoinしないと読めないのかと思ってました）
で、早速読んでおります。
ありがとうございました。
715 名前：デフォルトの名無しさん mailto:sage [04/12/28 14:52:24]: このaranskって馬鹿、ほんとに馬鹿だと思ってたら、関数型言語スレ読んで
どうしようもない馬鹿だとわかった。
716 名前：John mailto:sage [04/12/28 14:55:36]: とりあえず
mput.dip.jp/?date=20030912
を読んでプロトタイプベースを理解したつもりになった。

一番重要なのは
どのようにポリモーフィズムを実現するか
ということにある。

JavaやC++なんかの普通のOOというのは
木構造型に派生していく継承と、それらをまとめるインターフェースによって作られる。
一方で、プロトタイプベースというのはスロットというパーツの
組み合わせて作る。

ここで一番の違いはアクセス保護された変数の扱いにある。
継承の概念があるOOはprotectedというアクセス保護が有効になる。
一方で、プロトタイプベースでは
プロトタイプ間の共通変数を作れないデメリットがある。
しかし、プロトタイプ間は独立となっているため、切り離しが可能となる。
つまり、好きなプロトタイプを組み合わせることができるというメリットがある。
717 名前：John mailto:sage [04/12/28 15:02:14]: 言葉を変えると

クラスというのは
メソッドと変数がクラスの中で閉じていることを意味する。
オブジェクト指向では継承という概念で拡張し、
インターフェースという概念でグルーピングする。

一方、プロトタイプ指向でも
クラスはメソッドと変数で閉じている。
それらを足し合わせることで、新しいクラスを作ることができる。

この言い回しから思いつくのは
プロトタイプベースでは型によるエラーチェックができないことにある。
つまり、実行してみるまで、ポリモーフィズムできるかどうかがわからない。
一方、オブジェクト指向言語では、実行前に型のチェックをするために
コンパイル時にエラーチェックができる。
718 名前：デフォルトの名無しさん mailto:sage [04/12/28 15:05:57]: >>716-717
クラスベースにおけるクラスとインスタンスの区別が無くなった物がプロトタイプベースだと考えるとわかりやすいよ
クラスの継承もインスタンスの生成も、プロトタイプベースにおけるクローンで纏められている

コンパイル時にクラスが既に決定しているクラスベースでは、クラス≒型に見立てて型チェックできるけど、
プロトタイプベースでは実行中にインスタンスが生成されるため、機構が単純だが型チェックできない
719 名前：John [04/12/28 15:06:45]: 個人的には
コンパイル時の型によるエラーチェックは非常に強力だと思うことと、
親クラスを切り替えたいケースはまれであること
（特に動的に切り替えたいケースはまれだ）
から、プロトタイプより、オブジェクト指向をお勧めする。
720 名前：John [04/12/28 15:11:24]: >>718
>クラスベースにおけるクラスとインスタンスの区別が無くなった物がプロトタイプベースだと考えるとわかりやすいよ
これはおかしいと思うよ。

結局のところ、インスタンスの定義をしなくちゃいけないわけで、
その定義の仕方が違うだけ。
クラスの継承とインターフェースで定義するのが、オブジェクト指向
（インターフェースは純粋仮想クラス？だからクラスの一種か）

クラスの足し合わせでインスタンスを定義するのがプロトタイプベース
721 名前：John [04/12/28 15:12:03]: >これはおかしいと思うよ。
おかしいっていうのは、それじゃ理解できないって意味ね。
間違ってるって意味じゃないです。
722 名前：デフォルトの名無しさん mailto:sage [04/12/28 15:25:07]: 藻まいら仕事汁。
723 名前：デフォルトの名無しさん mailto:sage [04/12/28 15:30:56]: なんかSmalltalkもSelf(の類)も使ったこと無い人たちが大量に香ばしい妄想を・・・
724 名前：John [04/12/28 15:44:43]: >>723
SmallTalkは確かに（ｒｙ
だから使われな（ｒｙ
725 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:09:12]: >>716
全然違う
このスレの前のほう読め
726 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:10:04]: >>718
それは静的型付けと動的型付けの違い
727 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:10:59]: >>720
> （インターフェースは純粋仮想クラス？だからクラスの一種か）

全然違う。
728 名前：デフォルトの名無しさん [04/12/28 16:26:59]: 違うという時は正解を書こうね。
説得力ないよｗ
729 名前：デフォルトの名無しさん [04/12/28 16:31:00]: プロトタイプベースが動的型付けじゃなかったら
なんのうまみも無いので、プロトタイプベースは動的型付けでいいと思う。
逆に、オブジェクト指向は型を厳密に決めることができるので、
そのメリットは活かさないに越したことは無い。
と思うんだけど。

誰かメリットデメリットをまとめてくれ。

参考程度にどぞー
www.atmarkit.co.jp/fjava/rensai3/devworks05/devworks05_2.html
730 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:40:17]: >>728
正解は、インターフェイスはクラスではない。これで満足か？
731 名前：デフォルトの名無しさん mailto:sage [04/12/28 16:48:44]: 説得力が必要だと思った時には
結論だけではなくて、その理由を書こうね。
732 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:10:35]: 用語も事実認定も滅茶苦茶な奴が電波飛ばしてるな。
正答を知りたきゃ金払えと。
733 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:13:36]: 動的な言語の常として
これ以上変更する必要がないということがわかってても
それを固定化できないってのは辛いよね
例えばあるメソッドを持つ親が必須のオブジェクトなのに
「無い場合」という本質的に無意味な分岐を作る必要が出てくる
メソッドを呼ぶときはそれを毎回チェックしないといけない
静的クラス指向やインタフェースを持つ言語なら
そのメソッドないとそもそも実行すらできない、
って風に別の保障を付けられる

静的なプロトタイプベースは作れないかね
734 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:22:47]: せめて静的なインターフェースを作れる様にして、
それに合致しないオブジェクトをそのインタフェースを持つオブジェクトの
プロトタイプには選択できないようにするとか。
まあこの手段でもプロトタイプ設定時「選択できなかった場合」という
分岐は存在してしまうけど、
毎回メソッドごとに不安要素を抱えるよりは健全であると思う
インターフェース内での最適化も出来ると思うし
735 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:28:05]: 軟体動物に外骨格をかぶせるとか、そんな感じで
インターフェースを仮初の型とみなして、
そのぶんの動的なメソッドディスパッチを全て省略できるとか
プロトタイプベースの正攻法の最適化って、やっぱ消極的なキャッシュぐらいだろうし
静的な型やインターフェースを持ち込むことでかなり強力になるとおもうんだよね
736 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:35:55]: じゃあ作れよ。終了。
737 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:39:31]: ↑そんなレスしかしないなら書き込まないほうがマシだとか
ちょっとは考えないのかな
考えないんだろうね
まそういう人間はそうやって思いつきだけで行動して
そのうち人殺しまでやった後気付くんだよな
「愚かだった」って
738 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:53:12]: 自分のことはよくわかっているらしい
739 名前：デフォルトの名無しさん mailto:sage [04/12/28 17:55:34]: ま、736の愚か者具合は置いといて
プロトタイプベースがいつまでも軟体動物である必要はない。
甲冑でも着て体当たりもできるような頑丈な体を望むオブジェクトも必要だろうし
メソッドがないだけて終了する恐れのあるプログラムをジャンボ機や管制塔に
納品するわけにいかない
オブジェクトの状態を定数化できれば似たようなことができそうだがね
740 名前：デフォルトの名無しさん [04/12/28 18:22:10]: Common Lisp はどっち？
741 名前：デフォルトの名無しさん mailto:sage [04/12/28 18:25:11]: >>731
理由ねえ・・・sunのサイトからJava Language Definitionでもダウソして読め。
742 名前：デフォルトの名無しさん mailto:sage [04/12/28 18:27:36]: そもそもJavaだって動的型チェックしてるってのに二元論的ステレオタイプは思考停止の元ですな。
743 名前：デフォルトの名無しさん mailto:sage [04/12/28 20:54:23]: 動的型、静的型とかいうと正直混乱しますな

動的型＝データに割り当てられた型
静的型＝変数に割り当てられた型

でおｋ？
744 名前：デフォルトの名無しさん [04/12/28 21:08:52]: >>743
コンパイル前に型が決まっているか、（静的）
実行してみるまで型がわからないか（動的）
という違いでいいと思うよ。

静的なOOはそのオブジェクトの実態がなんだかはわからないけど
基底クラスなりインターフェース（純粋仮想クラス）なりがわかっているから
メソッド呼び出しが成功することが保証されてる。
745 名前：デフォルトの名無しさん [04/12/28 21:12:54]: プロトタイプベース（以下PTB)もOOPも
基本になってるのは
データとそれに関連するメソッドをパッキングしましょうってこと。
そして、その共通部分を抜き出して定義することで、
１．共通部分を1箇所に記述する
２．メソッドディスパッチ（ポリモーフィズム、動的バインド）で処理フローを簡略化する
ということだと思うんだけど
ここまでは正しいのかな？
746 名前：デフォルトの名無しさん mailto:sage [04/12/28 21:13:03]: 動的型・チェックだったのか
動的・型チェックだと思ってた
747 名前：デフォルトの名無しさん [04/12/28 21:16:55]: OOPではクラスの継承を利用してそこら辺を記述する。
PTBではクラスの足し合わせでそこら辺を記述する。

1つ疑問なのは
データとメソッドを「１つに」パッキングすることが目的なのに
PTBにおけるクラスの足し合わせだと
データは分断されたままなのではなかろうか？
getter/setterを用意すればいいんだろうけど、それって
面倒な気もする。

いまいちプロトタイプベースのうまみがわからない。
誰かわかる人解説してくれないか？
748 名前：718 mailto:sage [04/12/28 21:21:49]: >>720
すまぬ、ちょっと文面が正しくなかった

＞クラスベースのクラス継承とインスタンス生成の区別が無くなった物がプロトタイプベース

ちなみにこれは Io のドキュメントに書いてあったような希ガス
749 名前：1 mailto:sage [04/12/28 22:09:39]: とりあえずクラスベースのみを指してオブジェクト指向とかOOPと呼ぶのはやめて欲しいです。
どちらかと言えばプロトタイプベースの方がオブジェクトを重視していると思いません？
750 名前：デフォルトの名無しさん mailto:sage [04/12/28 22:11:27]: >>749
それは思いませんが上段には賛成ですね
751 名前：デフォルトの名無しさん mailto:sage [04/12/28 22:12:37]: >>747
>データは分断されたままなのではなかろうか？

super::memberとかproto->memberすればいいんじゃないの？
アクセス制限してるならともかく、
親見に行くのにgetter/setterなんて用意する必要ないでしょ
名前探索の方法は言語ごとに異なる要素だから一概にはいえないけど

そういやprivateとかpublicとか属性はあるのかね
752 名前：デフォルトの名無しさん mailto:sage [04/12/28 22:18:18]: しかし、親がすげ変わる可能性あるって、なんかまともじゃない感じだけど。
どうせ実装上の副産物みたいなものでプロトタイプベースの本質じゃない気がするし、
はやいとこそんな機能切ったほうがいいんじゃないのかね。

protoがhogeだったのに
いきなり
proto := hage
されていいことなんか何もなさそうだよ？
753 名前：デフォルトの名無しさん mailto:sage [04/12/28 22:22:52]: >>752
柔軟性を保つとトリッキーなことが出来るとは思うけど、
プロトタイプの本質≠プロトが改変可能かどうか
だと思う

親の挿げ替えは、正直あまり使わないな
754 名前：デフォルトの名無しさん mailto:sage [04/12/28 23:42:21]: javascriptは親の挿げ替え出来ないよ
755 名前：デフォルトの名無しさん mailto:sage [04/12/28 23:44:46]: とりあえず、プロトタイプチェインの挙動には幾つかの種類があると

親の挿げ替えができる／できない
親の変更が子に反映される／されない
756 名前：デフォルトの名無しさん mailto:sage [04/12/29 00:12:05]: 要するにクラスベースだとかプロトタイプベースだとか言ったところで継承を実現するためのデータ構造が少々ちがうっつー程度のことだ、って認識でOK?
757 名前：デフォルトの名無しさん mailto:sage [04/12/29 00:13:00]: じゃあ一番メジャーなjavascriptを基準にして話しようよ
他の変態プロトタイプベース言語のクセ話しても通じないこと多いし
javascriptは素人でも扱えるし
758 名前：デフォルトの名無しさん mailto:sage [04/12/29 00:23:38]: >757
ECMAScriptスレ行け
「メジャーだから～～の実装こそが○○を現わす」と騙るのは不毛だから止めようぜ
759 名前：デフォルトの名無しさん mailto:sage [04/12/29 03:33:25]: 誰か>>3 >>4 >>19辺りにあがってる言語の>>755みたいな違いを一覧にしろよ
話はそれからだ
760 名前：デフォルトの名無しさん mailto:sage [04/12/29 08:32:17]: クラスベースでも

クラスの挿げ替えができる
クラスの変更がインスタンスに反映される

な言語はあるでよ
761 名前：デフォルトの名無しさん mailto:sage [04/12/29 10:42:59]: >>749
前半賛成、後半反対。
プロトタイプベースもクラスベースも等価であって、
どちらが優れているかは、それ以外の技術要素(型システムやメタプログラミ
ング、リフレクション、例外、継続など)や処理系や開発環境との
「組み合わせの妙」のほうがずっと重要。
762 名前：Aransk [04/12/29 15:16:38]: 敢えてプロトタイプベース言語に対する反論の
立場から述べます。
ttp://mput.dip.jp/?date=20030912より引用：
>実行時に動的に先祖クラス(に相当するもの)が変更できます
>実行時に動的にメソッド定義やメソッド除去ができます。

プログラムは作成者の意思を反映させるものという
観点からして上記の操作が動的にできるメリットって
なんでしょうか？

>動的すぎてわけが分からなくなります :-)

これはstaticかつpublicに卓見だと思うのです。
763 名前：デフォルトの名無しさん mailto:sage [04/12/29 15:25:46]: 素人として>>762の疑問は湧くなぁ。
メリットとして上の方ではCoRが挙がってたけどそれっておまけだよな。
あとGUIのボタンとか、インスタンス固有の振る舞いが多くかつ混乱が起きにくい場合、か？
それのJavaのinterface+無名クラスとかC#のdelegateとかより優れてるトコってなんだろう？

モデルがシンプルできれい、というだけ？
764 名前：デフォルトの名無しさん mailto:sage [04/12/29 15:26:48]: どうでも良いんだけど、C# のクラスの中にデリゲート用の変数を
スロットの変わりに無限個 (なお、変数名が重ならないように) 作成したとすると、
プロトタイプベースっぽくなるような気がする
765 名前：デフォルトの名無しさん mailto:sage [04/12/29 15:27:54]: >>763
プログラム内で一個しか作らないオブジェクトに、わざわざ新しいクラスを作りたくない

とか
766 名前：デフォルトの名無しさん mailto:sage [04/12/29 15:52:03]: >>765
プログラム内で一個しか作らないモノのクラスをつくるのと
プログラム内で一個しか作らないモノのオブジェクトをつくるのと、
何が違う？
767 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:04:22]: >>766
singleton でぐぐるように

という誘導は置いておいて、例えば Web ページ上にボタンが配置されているときに、
そのボタンにメソッドを追加するのはプロトタイプベースのほうがやりやすいよな
768 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:08:25]: 静的言語か動的言語かが決定的な分水嶺であって、
クラスが動的な存在であれば、POOもCOOも大した違いはないんじゃないかと。
COOではお仕着せのクラス機構の代わりに、POOではシンプルな委譲機構が提供されているというだけで。

POO知らずにJavaScriptやったとき、「なんじゃこの手抜きなOO機構わ。ハハハ」と思った記憶があります。
それを踏まえてPOOのメリットって言うと、どうなんだろう。
769 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:12:03]: >>767
singleton くらい知ってるわヽ(`Д´)ﾉｳﾜｧｧｧーﾝ!!
わざわざsingletonなんてしないで無名クラスでやりゃ、
どのみち定義書いてオブジェクトにセットするって手間は変わらんだろっつってんだよ。
おまけにJava/C#なら型チェックもしてくれるぞ。
770 名前：デフォルトの名無しさん [04/12/29 16:18:59]: CLOS and MOP 最強伝説。
771 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:19:53]: ダスキンの掃除用具ですか？＞クロスとモップ
772 名前：デフォルトの名無しさん mailto:sage [04/12/29 16:20:19]: >>762
プログラムは作成者の意思を反映させるものという観点からして、
オブジェクトを直接記述できるプロトタイプベースのほうが
クラスを介してしか記述できないクラスベースよりも
その意思を直接反映させることができる、

ということにも気付かないのかなあ。
あいかわらず過去ログでの議論にも目を通してなさそうだし。
773 名前：デフォルトの名無しさん [04/12/29 16:29:03]: c++ぽくやるとすれば中間言語で…
774 名前：デフォルトの名無しさん [04/12/29 16:32:39]: >>772
それはつまり、>>763の最終行でFA、ということでよろしいか？
Aranskのような脳味噌クラス漬けが大半を占める世の中ではメリットとは言えまいて。
775 名前：デフォルトの名無しさん mailto:sage [04/12/29 17:36:46]: >>774
> それはつまり、>>763の最終行でFA、ということでよろしいか？

全然違うよ。
むしろプロトタイプベースの良いところはdirty hackingな状況で発揮される。
モデルがsimple&cleanであることと、記述が直接的であることは全然別問題。
776 名前：デフォルトの名無しさん mailto:sage [04/12/29 17:41:09]: >>775
クラスベースは「設計図から機械を作る」のに対し、
プロトタイプベースは「いっぱいあるジャックにプラグを色々組み合わせていく」イメージとか妄想してみると

クラスベースのほうが綺麗に作れるけど、プロトタイプベースのほうがごちゃごちゃしているが簡単に作れる？
777 名前：デフォルトの名無しさん [04/12/29 18:17:25]: >>775
dirty hackingな状況で発揮されるってことは、
書ける・書けないってとこが最重要で、それもさっくり書けるところがポイントだと思うが、
>>769の通り、クラスが動的なら、クラスベースもプロトタイプベースもさほどの違いはないのではないか？
778 名前：デフォルトの名無しさん mailto:sage [04/12/29 18:22:35]: JavaのMathクラスはクラスの意味が無い
779 名前：デフォルトの名無しさん mailto:sage [04/12/29 18:23:25]: >>778
ツールキットだからな
780 名前：デフォルトの名無しさん mailto:sage [04/12/29 18:25:20]: >>778
class の意味は『分類』だから、別にオブジェクト指向に縛られてなくてもいいんじゃないか？
781 名前：1 mailto:sage [04/12/29 18:45:49]: 既に動いてるオブジェクトを使ってプログラミングする時なんか
プロトタイプベースだと綺麗に記述できると思います。
使ったことないけどDOMで便利だっていうのはそういうことですよね。

例えばEmacs Lispなどのいじくり回す必要があるアプリレベルを叩く言語とか。
システムを一から作り上げるのはクラスベースの方がいいかもしれないけど、
システムを表面から操作するのはプロトタイプベースの方がスマートだと思います。
システムの上で別のシステムを動かすことまで考えると一概には言えませんけど。

Smalltalkがクラスベースなのはそのせいかなぁ。
システム記述とシステム操作の言語を統一することを考えた場合、
プロトタイプベースよりクラスベースの方が良さそうだということかなぁ。
それともプロトタイプベースなど考えつかなかったのか。
782 名前：デフォルトの名無しさん mailto:sage [04/12/29 18:51:42]: >>781
> システムを一から作り上げるのはクラスベースの方がいいかもしれないけど、
> システムを表面から操作するのはプロトタイプベースの方がスマートだと思います。

その通りだと思う。
あるいは、記述するだけならプロトタイプベースのほうがhandyでdirectに記述できる。
が、他人に理解してもらおうと思ったらクラスベースのほうが整理しやすいんじゃないかな。

> Smalltalkがクラスベースなのはそのせいかなぁ。
> システム記述とシステム操作の言語を統一することを考えた場合、
> プロトタイプベースよりクラスベースの方が良さそうだということかなぁ。
> それともプロトタイプベースなど考えつかなかったのか。

Kay的には、例えばeToysのようにクラスベース上にインスタンスベースな環境を
構築すればいいだけという(無意識の)見切りがあったんじゃなかろうかと思う。
だが、一般のOO屋は、そこにあるクラス群こそがSmalltalkだと思ってしまった
のではないかと。
783 名前：デフォルトの名無しさん [04/12/29 18:55:21]: ごちゃごちゃ言わんと優れたソフトウェア&システムを作れってことだ。
思想や書き方云々は金にならん。
784 名前：デフォルトの名無しさん [04/12/29 19:50:41]: ごちゃごちゃ言わんと、コードで示せ！

>>783
2chで文句垂れてても金になりませんよ。
785 名前：デフォルトの名無しさん mailto:sage [04/12/29 19:58:13]: >>784
You show: theCode
786 名前：デフォルトの名無しさん mailto:sage [04/12/30 16:13:19]: javascript＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ﾌﾟ(ry
787 名前：デフォルトの名無しさん mailto:sage [04/12/30 19:20:55]: Ruby ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
788 名前：デフォルトの名無しさん mailto:sage [04/12/30 20:13:59]: >>787
おい、Ruby よりも低級な言語が存在していないぞ
789 名前：デフォルトの名無しさん mailto:sage [04/12/30 21:13:00]: 787 名前：デフォルトの名無しさん [sage] 投稿日： 04/12/30 19:20:55
Ruby ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ 788 名前：デフォルトの名無しさん [sage] 投稿日： 04/12/30 20:13:59
>>787
おい、Ruby よりも低級な言語が存在していないぞ
790 名前：デフォルトの名無しさん mailto:sage [04/12/30 21:16:37]: 787 名前：デフォルトの名無しさん [sage] 投稿日： 04/12/30 19:20:55
Ruby ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ 788 名前：デフォルトの名無しさん [sage] 投稿日： 04/12/30 20:13:59>>787
おい、Ruby よりも低級な言語が存在していないぞ
791 名前：デフォルトの名無しさん [04/12/31 08:21:43]: Rubyｷﾁｶﾞｲ顔真っ赤記念晒しage
792 名前：Aransk [04/12/31 17:49:02]: 無茶苦茶レベルを落として申し訳ないが
Ioってどうしたら日本語通じるの？
「Io>」プロンプトのあと色々と
やってみたがどうもうまく行かない。
アドオンを付加すれば一応ユニコード
OKみたいなことをHPには書いてあるよう
だけど…。
793 名前：Aransk [04/12/31 19:24:13]: ちょっとレベルを上げます。
どうも良く分からないんですが、プログラミング
パラダイムそのものを考えた場合に
「main メソッドの喪失」
ってどうなんでしょうねぇ。
これはプロトタイプ言語だけではなく
スクリプト系言語全般に言えることで
すが、プログラムの構造化の観点からすれば
逆流はしてますよね。
794 名前：デフォルトの名無しさん mailto:sage [04/12/31 20:28:48]: >>793
当たり前だろ？　構造化とは逆方向を行くのが関数指向や論理指向、もろもろの非手続き指向なんだし
それから、構造化がプログラムの質を上げるというのは必ずしも正しいことじゃないよ
795 名前：デフォルトの名無しさん mailto:sage [04/12/31 20:43:36]: ……なんか俺変な事言ったような気がする
ぬるーよろ
796 名前：689 mailto:sage [04/12/31 22:00:05]: >793
main メソッドが消失しているのではなく、トップレベルがmain メソッドに
なっているだけのこと。
スクリプト系は頭から逐次処理されることを想定しているから、
わざわざスタート地点を指定する必要が無いだけですな。

メリット
・プログラムするときに、逐次処理部分と定義部分を分けて考える必要が無い
・処理系を作るのが（逐次処理だけで済むので）ラク

デメリット
・（どの部分をあらかじめ処理していいのかのヒントが少なくなるので）
　最適化しにくい

純粋関数型でも同様だと思う。
797 名前：デフォルトの名無しさん mailto:sage [04/12/31 22:50:11]: main についてはその通りだと思うが、関数型言語の中でも Haskell は main
という関数を定義しないと動かないし、結局は処理系の設計者がどう考えて設
計したか、ってだけだと思うんだがな。

つうかAranskにマジレスしても無駄。
798 名前：デフォルトの名無しさん mailto:sage [05/01/01 03:56:59]: >>797
> 結局は処理系の設計者がどう考えて設
> 計したか、ってだけだと思うんだがな。

だよね。
少なくともOOやクラスベース/プロトタイプベースとは直交した概念だと思う。
799 名前：Rubyist! [05/01/01 13:46:26]: おめーらがやってる批評もどきのRubyに対する足引っ張りはな、
十把一絡げの愚図Java,C++,Perlみたいなカス言語フリーク野郎が
Ruby作者matzのような結果を出した人間と自分との格差を認められず
おこがましくも精神的に一矢報いようとするために
仰々しく「批評」とか名付けた浅ましい自己主張で攻撃して
自尊心を慰めてるにすぎない。

実際問題として、お前みたいな奴が考えてるほど
批評された側の役に立ってるわけがないだろ？ボケが。
その口から出るクソが誰かに感謝でもされたか？ああ？
自意識過剰甚だしいんだよ、この自己愛のボケ奴隷が。
数倍マシ？寝言は寝て言えよこの恥知らず野郎。
ネットで万能感むき出しにしてオナってんじゃねーよ。

批判する野党が重要だぁ？ﾌﾟ
公明党にでも投票してろ白痴野郎。
800 名前：デフォルトの名無しさん mailto:sage [05/01/01 16:25:47]: >799
すみません、SELF, NewtonScript, IO, soopy マンセーなんですけど……
（実際に使っているわけじゃないけどね……）
>3-4見た？
801 名前：デフォルトの名無しさん mailto:sage [05/01/01 16:32:54]: >>799
３行目まで読んだ。
＞Ruby作者matzのような結果を出した人間

「ような」だと、係る部分が不確かなので、「ように」のほうがいいと思われ。
802 名前：Aransk [05/01/01 17:07:48]: >メリット
>・プログラムするときに、逐次処理部分と定義部分を分けて考える必要が無い
>・処理系を作るのが（逐次処理だけで済むので）ラク
逐次処理と定義部分がごっちゃになって可読性に欠けることが
一つさらに、
処理系に対しても負荷が大きいような気がします。
つまりmainを無くしたことのメリット、デメリットを
冷静に見る必要があると思う次第です。
（RubyやMatzに対して特に含むところはありません。
くれぐれも誤解しないで下さい。）
803 名前：デフォルトの名無しさん mailto:sage [05/01/01 17:40:11]: >>802
> 逐次処理と定義部分がごっちゃになって可読性に欠けることが

「定義する」という動作を逐次処理しているだけの話でしょ。

> 処理系に対しても負荷が大きいような気がします。

どうして？詳細きぼん、ってaranskに言ってもしょうがないか。
804 名前：デフォルトの名無しさん [05/01/01 21:46:47]: >既に動いてるオブジェクトを使ってプログラミングする時なんか
>プロトタイプベースだと綺麗に記述できると思います。
具体例きぼんぬ
妄想で終わらせると机上の空論で終わるよ。

rubyにmainがあろうがなかろうが変わらないでしょ。
最初に必要な全ての関数（クラス）定義を一度読み込まなきゃいけない。
あるいは、関数が現れたら探さなきゃいけない。
rubyだと、ある関数が呼ばれた時にそれがどこの記述されているかを
探さなきゃいけないんで、（最悪見つからないことも・・・）
結局のところ、一番最初にがばって読み込んでから、
処理を開始するのが普通のやり方だと思うけど。

>逐次処理と定義部分がごっちゃになって可読性に欠けることが
そんなことは言語仕様で定めなくても、誰もやらん。

>処理系に対しても負荷が大きいような気がします。
気のせいだろ。

個人的にはJavaの言語仕様がスマートでかっこいい。
805 名前：689 mailto:sage [05/01/02 03:00:35]: >802
>逐次処理と定義部分がごっちゃになって可読性に欠けることが
ああ、スマン。確かに可読性は落ちるけど、書くのがラクなのよ。
取りあえず動くもの作って、その後にリファクタリングで可読性を上げる
というXPチックなことがやりやすいのですな。

あと、C++なんかだとよくやるけど、「使う直前で定義する」つうのも
やりやすくなるよ。定義したものの有効範囲が狭い場合は、むしろ
こっちの方が可読性が高い。

>処理系に対しても負荷が大きいような気がします

そう？
最適化しづらいつうのはあるかもしれないけど、負荷に関しては
こんなところに依存しないと思うけど……

>RubyやMatzに対して特に含むところはありません。
世の中のスクリプト言語って、大抵トップレベルがmain じゃなかったっけ？
806 名前：689 mailto:sage [05/01/02 03:06:16]: >804
>結局のところ、一番最初にがばって読み込んでから、
>処理を開始するのが普通のやり方だと思うけど。

Rubyも全ソースを構文木に加工してから実行するタイプだと思うけど……
807 名前：デフォルトの名無しさん mailto:sage [05/01/02 16:33:11]: rubyだったらスクリプトの末尾に main(*ARGV) if $0 == __FILE__ で十分だと思うけど。

反例として、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"]
808 名前：807 mailto:sage [05/01/02 16:56:29]: -- 807の続き

他の言語で類似例を挙げれば、
例えば、Prothonでもモジュールとオブジェクトの差異をなくすことで、
importしたモジュールをそのままオブジェクトとして扱う事を可能にしていますね。
クラスとオブジェクトのをフラットな関係にしたように、
モジュールもオブジェクトにしてしまえば区別する必要がなくなる。
プロトタイプベースと呼んでいいものかどうかわかりませんが、
実装を考えれば自然な発想で、プロトタイプベースに通じるものがあると思います。

話をmain関数に戻します...。

main関数がある(かつクラスとモジュールの境界がない)と、pike の様に
トップレベルに書かれたコードをclassに見立てて再利用する事が可能になります。
トップレベルに全て書いてしまうと、モジュールとして呼ばれた時にコードが実行されて
しまう為、
プログラム単位での再利用が難くなります。

もっとも、main関数がなくても自分で定義すれば済む話なので、
後はモジュール化さえしっかりしていれば、実際に困る事は殆んどありません。
多くのスクリプト言語では、プログラムがモジュールとして要求されたのか、
単体でよばれたのかを明示的にチェックする事でこの問題を回避しています。

トップレベルがmainな場合の利点は周知のようなので割愛。
main関数のある言語でのプロトタイプっぽい事例ということで、無理矢理繋げてみました。
809 名前：デフォルトの名無しさん mailto:sage [05/01/02 17:40:46]: >>808
> プロトタイプベースと呼んでいいものかどうかわかりませんが、
> 実装を考えれば自然な発想で、プロトタイプベースに通じるものがあると思います。

モジュールはコピれないところがちょっと厳しいけど、
オブジェクト的なエンティティの直接記述という意味では
確かにプロトタイプベース的だよな。
810 名前：デフォルトの名無しさん mailto:sage [05/01/15 15:32:03]: 思ったんだけど、プロトタイプベースの真髄を「クラスを必要としないオブジェクトの生成」にあるとすると、
別にクラスベースとオブジェクトベースが相反する概念ってわけじゃないんじゃないか？

クラスから生成したインスタンスをプロトタイプベース並みに改変できるというわけで
クラス＝型とみなしての型付けは、やりにくいかもしれないが
811 名前：デフォルトの名無しさん mailto:sage [05/01/15 16:25:05]: >>810
それクラスベースの意味がないと思う。
プロトタイプでも「設計図を渡してそれに沿ったオブジェクトを返す」ってルーチン作ればいいだけだし
812 名前：デフォルトの名無しさん mailto:sage [05/01/15 16:25:46]: javascriptが丁度そんな感じ
813 名前：デフォルトの名無しさん mailto:sage [05/01/15 16:36:00]: >>811
> それクラスベースの意味がないと思う。

どうして？

> プロトタイプでも「設計図を渡してそれに沿ったオブジェクトを返す」ってルーチン作ればいいだけだし

つーか、それってクラスがfirst class objectなOO言語(例えばSmalltalk)そのものじゃん。
814 名前：デフォルトの名無しさん mailto:sage [05/01/15 16:50:03]: >クラスから生成したインスタンスをプロトタイプベース並みに改変できるというわけで
それRubyの特異メソッド(クラス)
815 名前：デフォルトの名無しさん mailto:sage [05/01/17 01:17:36 ]: メソッド起動に関していえば、インスタンスベースとクラスベースの違いは、
オブジェクトがクラスに委譲せずに起動可能なメソッドを持てるかどうかに
尽きます。
816 名前：デフォルトの名無しさん mailto:sage [05/01/17 02:39:52 ]: Rubyが実用とは程遠いことがよくわかった
817 名前：デフォルトの名無しさん mailto:sage [05/01/17 19:14:28 ]: じゃあPythonも一緒？
818 名前：デフォルトの名無しさん mailto:sage [05/01/19 20:28:30 ]: なんかクラスベースとプロトタイプベースの区別がわかんなくなったので、
「実行前にオブジェクトの挙動が決定されるかどうか」
って線引きをしてみたんだけど合ってる？

すると、ruby なんかのスクリプト系がまたよくわかんなくなるんだけど、如何なものか
819 名前：デフォルトの名無しさん mailto:sage [05/01/19 22:07:57 ]: >>818
それは「静的か動的か」の線引きでは？
820 名前：818 mailto:sage [05/01/19 22:19:57 ]: >>819
クラスをコードとして記述できるかどうかの意味で引いてみた
インスタンスをコードに記述することはできないやん
821 名前：デフォルトの名無しさん mailto:sage [05/01/19 23:39:34 ]: 何いってんだかさっぱりわからんよ
822 名前：1 mailto:sage [05/01/20 00:19:16 ]: 私はソース上のプリミティブな要素がクラスなのかインスタンスなのかを
基準と考えておりますがどうでしょうか。
823 名前：デフォルトの名無しさん mailto:sage [05/01/20 08:14:59 ]: >>822
つまり、実行機構および言語機能による分類ではなく、言語表現による分類であると。
なかなか興味深いと思います。
今まで出てきたプロトタイプベースの特性について、その分類がどのように関与するか
検討してみると面白いかもしれません。

1. 実行時メソッド変更
2. 実行時スロット拡張
3. 実行時プロトタイプ変更
824 名前：デフォルトの名無しさん mailto:sage [05/01/20 14:18:23 ]: >>822 >>823

オブジェクト指向って、まだ良くわかんないんだけど
その話題はなんとなく面白そうなので、もっと展開してほすぃ。
825 名前：デフォルトの名無しさん mailto:sage [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)の実装では、これらは設計上自然に備わっている特徴として捉える事が出来る。
826 名前：818 mailto:sage [05/01/22 12:39:40 ]: >>822
なんか、微妙に俺が考えてたものとニアミスしている気がする
俺はつまり、クラスを記述できちゃったらクラスベースと考えたわけだが
827 名前：823 mailto:sage [05/01/22 14:25:14 ]: >>826
俺的には、クラスを記述できるかどうかはあまり本質ではないと思う。

俺は逆に、任意のオブジェクトを1つのリテラル表現として記述できるかどうかが
インスタンスベース言語であるかどうかを判断する表現上の基準になるんじゃないかと
思うのだが。
828 名前：デフォルトの名無しさん mailto:sage [05/01/22 19:52:57 ]: プロトタイプベース初心者です。
www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html
このへんを読むと、プロトタイプベースの言語では、あるインスタンスの
スロットを探してメソッドがなかったら、その親のスロットを捜しに行くように
読めます(これがプロトタイプチェーン?)。
素人目には、こんなことをしなくても、clone()の時点でスロット全部コピー
すればよさそうに思えるのですが、この動作の利点は何なんでしょうか?
a)スロットのメモリ領域を節約できる(微々たるもんだよなー)
b)親のメソッドを差し替えたり、親にメソッドを追加したとき、
　子からも新しいのを使うことができる。
程度しか思いつきません。
b)は、正直、「こんなことやっちゃっていいの?」と思います。
対話的なプログラミングなら嬉しいかもしれないけれど。
829 名前：デフォルトの名無しさん mailto:sage [05/01/22 19:58:48 ]: プロチ初心者というよりは動的言語初心者未満だな。
830 名前：818 mailto:sage [05/01/22 20:01:41 ]: >>827
え～!?

「newobj = obj.Clone();」とかやっても、インスタンスを記述したことにならないやん
インスタンスは変数の裏に隠れて移動するだけだし

リテラルとして考えると、「1」とか「"text"」とかは確かに記述できるけど、
それはクラスベースでもプロトタイプベースでも、あまり変わらないし

任意のオブジェクトを記述できる手段として“クラス”があると捕らえているのよ
それを 1st class object と捕らえるとか、そういう話云々は別として
831 名前：828 mailto:sage [05/01/22 20:50:26 ]: >>829
まあそうなんでしょうねえ。

読み返していたら、>>58を見付けました。

> 画面にたくさんのテキストフィールドがあって、
>それのイベントハンドラをいっせいに切り替えるようなこと。
>画面のモードによって、いっせいにフィールドの挙動を変えるようなこと。

たとえば画面上のボタンを押した時点でこういう挙動を起こしたければ、
「スロットまるごとコピー方式」だけじゃうまくいきませんね。
832 名前：デフォルトの名無しさん mailto:sage [05/01/22 22:44:26 ]: >>830
基本的に分かっちゃないくせにぶっちゃう莫迦だなコイツ。放置の方向か？
833 名前：818 mailto:sage [05/01/22 23:03:49 ]: >>832
ああ、俺が馬鹿なのは否定できないし、スルーしても別にかまわないし、
そういえば 827 と 830 は微妙に話が噛み合ってないと今更突っ込みたくもなったけど、

基本的に、リテラルを除けば
「記述できるインスタンス」と「記述できないクラス」は存在しないとは思っている
834 名前：デフォルトの名無しさん mailto:sage [05/01/22 23:10:33 ]: >828
IOのcloneはスロット全部コピーするらしいよ。

効率を考えると全部コピーした方がいいけど、b)の柔軟性も
魅力的。

個人的にはcloneは全コピーで、それとは別にdelegateが
あったほうがいいなあ。
835 名前：828 mailto:sage [05/01/22 23:24:44 ]: >>834
>IOのcloneはスロット全部コピーするらしいよ。

え、そうなの?
俺、↓読んで、てっきり逆だと思ってました。

sumim.no-ip.com:8080/wiki/493
| 実手続きとしてチャイルドを作るときに clone（あるいは clone() ）を
| 使用できるものと、clone は copy（shallow copy）と同義で、
| 単にプロトタイプの複製を作るだけのものがありまぎらわしい。
| 実は Io を除き、ほとんどの言語は後者で、むしろこのほうが一般的。
| つまり、我々が一般にイメージするクローン（じつはチャイルド）を
| clone で作ることはできない。
836 名前：デフォルトの名無しさん mailto:sage [05/01/22 23:27:44 ]: >>835
shallow copy って事は、スロットを複製しない浅いコピーって解釈で良いんじゃない？
Io は前者、つまり clone でスロットも複製するって感じで
837 名前：デフォルトの名無しさん mailto:sage [05/01/23 00:46:44 ]: 何のための proto かと
838 名前：デフォルトの名無しさん mailto:sage [05/01/23 00:56:56 ]: まあ2chじゃよく見るわけだが。
>>829とか>>832とか>>837とか、具体的なことを何も言わずに、1行かそこらのレスで
何か偉そうなことを言った気になれる奴ってのは楽でいいね。

ｵﾚﾓﾅｰ
839 名前：デフォルトの名無しさん mailto:sage [05/01/23 01:27:54 ]: >>834
全部コピーはしてないよ。
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 唯一つ。
840 名前：デフォルトの名無しさん mailto:sage [05/01/23 05:01:29 ]: >>828
スロットをコピーするといっても、実態を全部コピーするわけではなく、
その参照をコピーするだけに留めるとクローン生成時のコストは抑えられる。
スロット追加時に、その参照から実態を複製しそこに新しいスロット追加する。
841 名前：823 mailto:sage [05/01/23 07:34:46 ]: >>830
> 「newobj = obj.Clone();」とかやっても、インスタンスを記述したことにならないやん

・・・
そういうのを排除するためにわざわざ「リテラルで」という限定詞を入れたんだけど。

> リテラルとして考えると、「1」とか「"text"」とかは確かに記述できるけど、
> それはクラスベースでもプロトタイプベースでも、あまり変わらないし

例えば、
cat = object {
mew(times) { self.make_sound("mew") }
walk(direction, distance) { self.dir = direction. self.move(distance) }
...
}
みたいな話ができてやっと「インスタンスベース」と言えるんじゃないか、って話な。
842 名前：デフォルトの名無しさん mailto:sage [05/01/23 07:44:00 ]: >>841
javascriptならそれでできるぞ
843 名前：823 mailto:sage [05/01/23 09:22:03 ]: >>842
ですよね。そういうのをインスタンスベース(あるいはプロトタイプベース)と呼ぶのが
言語表現上の分類として適切なのではないかと。
844 名前：デフォルトの名無しさん mailto:sage [05/01/23 09:56:09 ]: rubyもできるぞ

str = "string"
845 名前：デフォルトの名無しさん mailto:sage [05/01/23 10:11:28 ]: >>844
文字列以外のオブジェクトは?
846 名前：823 mailto:sage [05/01/23 10:20:27 ]: >>844
> str = "string"

そういうのを排除するために「任意のオブジェクトを」1つのリテラル表現として
記述できるかどうか、と書いたのだが。
847 名前：デフォルトの名無しさん mailto:sage [05/01/23 10:47:50 ]: >>841
こういうのもリテラルと呼ぶのか

cat = object(
mew(times) { self.make_sound("mew") },
walk(direction, distance) { self.dir = direction. self.move(distance) },
...
);
848 名前：デフォルトの名無しさん mailto:sage [05/01/23 10:52:58 ]: >>836
ちゃう、ちゃう。ここで“前者”はディープコピーではなくて、チャイルド（プロトチェーンに
委譲する、俗に“クローン”と呼ばれているもの）を作ること。Io は clone でチャイルド
を作るけど、SELF などは clone でチャイルドを作らずにシャローコピーを作るってこと。
849 名前：デフォルトの名無しさん mailto:sage [05/01/23 10:57:38 ]: >>846
>>815じゃ駄目なの？　これに尽きると思うけど。
850 名前：デフォルトの名無しさん mailto:sage [05/01/23 11:15:20 ]: javaのMathはオブジェクトを直接書いてるように見える。
メソッドも自己完結してる
851 名前：デフォルトの名無しさん mailto:sage [05/01/23 11:25:42 ]: >>850
ぜんぶstaticやん。Mathはネームスペースを提供しているだけだがな。
852 名前：823 mailto:sage [05/01/23 12:14:39 ]: >>849
>>815はメッセージ送信の実行機構による分類でしょ。
もちろんそれはそれで1つの正しい分類だしそれに異存はない。
が、今は言語表現による分類をするとしたら、という話をしているわけ。
853 名前：823 mailto:sage [05/01/23 12:15:58 ]: >>850
javaのMathで「任意の」オブジェクトをリテラル表現できるわけ？
リテラルってのは定数表現だよ、念のため。
854 名前：デフォルトの名無しさん mailto:sage [05/01/23 12:30:45 ]: >>841
字面を見る限り、Javaの無名クラスとどう違うのかって気が…
855 名前：823 mailto:sage [05/01/23 16:47:52 ]: >>854
> 字面を見る限り、Javaの無名クラスとどう違うのかって気が…

だからさ、そこがポイントなわけよ。
Javaの無名クラスはあくまでクラスでしょ。
それをインスタンスに対してできてこそのインスタンスベースじゃない？
856 名前：デフォルトの名無しさん mailto:sage [05/01/23 17:09:42 ]: >Javaの無名クラスはあくまでクラスでしょ。

んー、それはJavaがクラスベースな言語なんだから当然の話であって、
こういう書き方ができるかどうかって事と、
クラスベースかインタスタンスベースかって事は直交した問題なんじゃ?
857 名前：818 [05/01/23 19:08:46 ]: >>841, >>854-856
＞例えば、
＞cat = object {
＞mew(times) { self.make_sound("mew") }
＞walk(direction, distance) { self.dir = direction. self.move(distance) }
＞...
＞}
＞みたいな話ができてやっと「インスタンスベース」と言えるんじゃないか、って話な。

実は、やっとココで >>818 の話に繋がるんです
仮に cat に代入されるオブジェクトが『実行時、今まさに作られるのならば』インスタンスベース
しかし、オブジェクトを生成する為の“メタオブジェクト”と呼べるものが『既に作られていたのならば』クラスベース
では無いかと思ったわけで
858 名前：デフォルトの名無しさん mailto:sage [05/01/23 19:09:17 ]: すまん age ちまった許して……っていうか石投げないで……
859 名前：823 mailto:sage [05/01/23 19:12:17 ]: >>856
> >Javaの無名クラスはあくまでクラスでしょ。
>
> んー、それはJavaがクラスベースな言語なんだから当然の話であって、

でしょ。
だったら、インスタンスベース言語ならそういう表現ができて当然なんじゃない？
860 名前：デフォルトの名無しさん mailto:sage [05/01/23 19:14:31 ]: >>859
少なくとも Io でそういう表現は出来なかったと思う
861 名前：823 mailto:sage [05/01/23 19:15:42 ]: >>857
> 実は、やっとココで >>818 の話に繋がるんです
> 仮に cat に代入されるオブジェクトが『実行時、今まさに作られるのならば』インスタンスベース

実行時に生成されるかコンパイル時に定数として生成されるかで振舞いが変わるかな？
いずれにせよ、そのオブジェクトの動作はリテラルとして記述された通りなわけで。
862 名前：823 mailto:sage [05/01/23 19:17:03 ]: >>860
> 少なくとも Io でそういう表現は出来なかったと思う

まあそういう例もあるだろうね。
その場合はプロトタイプを使ってオブジェクトを生成するしかないから、
インスタンスベースとプロトタイプベースを区別したほうがいいのかも。
863 名前：818 mailto:sage [05/01/23 19:23:05 ]: >>861
＞実行時に生成されるかコンパイル時に定数として生成されるかで振舞いが変わるかな？
あ、↑みたいに言った方が良かったかも ^-^;

件のコードは、
「object まで到達した時点でオブジェクトが作成され、次いで mew と walk が接続され、そして cat に代入される」
……なら、実行時に作ったということでインスタンスベース
「object まで到達した時点で、既に完成されたオブジェクトが生成され cat に代入される」
……なら、クラスベース
ということで
864 名前：デフォルトの名無しさん mailto:sage [05/01/23 19:36:40 ]: >>862
おいおい。自説大事に生粋のインスタンスベースを例外扱いかよ。
真性だな。
865 名前：デフォルトの名無しさん mailto:sage [05/01/23 19:40:28 ]: >>862
プロトタイプベースとインスタンスベースとオブジェクトベースは
同じものの別の呼び名です。念のため。
866 名前：818 mailto:sage [05/01/23 19:44:09 ]: そういえば俺が見た本の中には
『プロトタイプベース』『クラスベース』『オブジェクト指向』がそれぞれ違う概念として紹介されて棚w

クラスが無ければプロトタイプベース、
継承しなければクラスベース、
継承してればオブジェクト指向

ってな感じに。俺は違和感あった
867 名前：デフォルトの名無しさん mailto:sage [05/01/23 19:49:30 ]: 無名だろうとクラスにメソッドを定義しないといけないのならクラスベースだよ。
シンタックスの妙でインスタンスベースっぽさを名乗るのは勝手だが。
インスタンス特異と見せかけて特異クラスを使うRubyの特異メソッドもしかり。
868 名前：デフォルトの名無しさん mailto:sage [05/01/23 20:03:36 ]: >>867
んじゃこれどう見る？

class Hoge begin
    proc void Fuga begin
        ～
    end;
end;

これがインスタンスベースだって言ったら怒る？
この場合はルートのオブジェクトに対して class メッセージを送ってみたんだが
すると、Hoge という名のクラス（1st class object）が生成される、という仕組み
869 名前：デフォルトの名無しさん mailto:sage [05/01/23 20:05:32 ]: >>866
まあとにかく、経験則のみで既存概念の再定義をやたら試みようとするのが
オブジェクト指向界隈の悪しき慣習だから、オリジナルペーパーや出典を明らか
にしない解説の類は眉唾で読まないとね。自分が紹介したり解説している考え方
の出所すらしらずに文章を書いて（カネまでもらってｗ）いるヤツのなんと多いことか。
870 名前：デフォルトの名無しさん mailto:sage [05/01/23 20:10:44 ]: >>869
>自分が紹介したり解説している考え方の出所すらしらずに
>文章を書いて（カネまでもらってｗ）いるヤツのなんと多いことか。

だって、全部自分の「再発明」なんだもん・・・
871 名前：デフォルトの名無しさん mailto:sage [05/01/23 20:15:25 ]: >>868
classメソッドはどこに定義されているの？
872 名前：デフォルトの名無しさん mailto:sage [05/01/23 20:18:52 ]: >>871
ルートオブジェクト

ちなみに、ルートオブジェクトはこの言語の世界が生まれたときには既に存在していました
つまり神に相当するオブジェクトです

……ま、でっちあげの脳内言語だけどな
873 名前：868 mailto:sage [05/01/23 20:22:14 ]: 肝心なのは、クラスとインスタンスの間に越えられない壁が有るという事……なのか？
この当たりはよく分からん
874 名前：デフォルトの名無しさん mailto:sage [05/01/23 20:26:53 ]: >>872
じゃあインスタンスベースでいいけど、脳内じゃな…　ｗ

そもそもHogeとかFugaとか関係ないし。わけわかめ。
875 名前：デフォルトの名無しさん mailto:sage [05/01/23 20:45:18 ]: >>874
うん。脳内。

だけど、基盤は出来てるから class メソッドをちゃんと組み込めばいいだけ。
面倒だからやりたくないけど。
876 名前：デフォルトの名無しさん mailto:sage [05/01/23 21:46:04 ]: 面倒なのがクラスベース
お気軽なのがプロトタイプベース
適当なのがインスタンスベース
877 名前：デフォルトの名無しさん mailto:sage [05/01/23 21:49:59 ]: クラスベース⇔オブジェクトベースだと思ってたけど。
878 名前：デフォルトの名無しさん mailto:sage [05/01/23 22:16:50 ]: >>859
>> んー、それはJavaがクラスベースな言語なんだから当然の話であって、
>でしょ。
>だったら、インスタンスベース言語ならそういう表現ができて当然なんじゃない？

「でしょ」じゃなくってさあ。
クラスベースの言語でも、無名クラスのような表現ができるのとできないのとがあるように、
インスタンスベースの言語でも、こういう表現ができるのとできないのがあっていい。
だから、この表記ができるかどうかの問題と、その言語がインスタンスベースであるか
どうかの問題は、直交している、って言ってるの。
879 名前：デフォルトの名無しさん mailto:sage [05/01/23 22:19:10 ]: >>878
『直交』という表現よりも『ニアミス』というか『次元がズレている』っていう表現の方がよくないか？

まぁ、書き方は幾らでも考え付くんだ
そのなかで『プロトタイプベースって一体何？』って話だよな？
880 名前：デフォルトの名無しさん mailto:sage [05/01/23 23:33:57 ]: >>877
だから対立した考え方じゃないんだってば。クラスベースで、インスタンスが自前の
メソッドや属性を自由にできない…という制約をといたのが、インスタンスベースだ。
881 名前：デフォルトの名無しさん mailto:sage [05/01/23 23:41:50 ]: >>876
くどいようですが、インススタンスベースとプロトタイプベースは同じものです。
プロトタイプベースというと、プロトタイプの複製でオブジェクトを生じさせること
やプロトタイプチェーンによる委譲といった、特徴だけど、本質ではないところ
のみ取りあげて、やたらクラスベースと対比させたがる人が多いので困ります。
882 名前：デフォルトの名無しさん mailto:sage [05/01/23 23:45:35 ]: >>881
『複製でオブジェクトを生じさせる』を『クラスに因らないオブジェクト生成』だと解釈すれば本質だと思うけど
883 名前：デフォルトの名無しさん mailto:sage [05/01/24 00:04:49 ]: それぞれ視点が違うだけなのに困られても・・・。
884 名前：デフォルトの名無しさん mailto:sage [05/01/24 00:36:32 ]: >>882
いや。それが本質じゃないだってば…。orz
885 名前：デフォルトの名無しさん mailto:sage [05/01/24 00:44:58 ]: >>883
プロトタイプの語感からくる間違った認識で議論されるのは困ると思う。
だからインスタンスベースかオブジェクトベースと呼ぼう！
A Theory of Object でもオブジェクトベースって言っているしね。

tinyurl.com/3tnke
886 名前：823 mailto:sage [05/01/24 12:07:41 ]: >>863
> 「object まで到達した時点で、既に完成されたオブジェクトが生成され cat に代入される」
> ……なら、クラスベース

クラスは存在せず、プロトタイプからコピーする場合でも、クラスベースと呼ぶ？
887 名前：823 mailto:sage [05/01/24 12:09:08 ]: >>865
はい。それ承知の上で、あえて区別分類してみようかと。
というのも、インスタンスベースだからといってプロトタイプという概念が
必然かどうかはまだ議論の余地があると思っています。
888 名前：823 mailto:sage [05/01/24 12:12:16 ]: >>868
> これがインスタンスベースだって言ったら怒る？
> この場合はルートのオブジェクトに対して class メッセージを送ってみたんだが
> すると、Hoge という名のクラス（1st class object）が生成される、という仕組み

クラスが存在する時点でクラスベースとおもわれ・・・

というか、それがインスタンスベースだと言うのならSmalltalkはインスタンスベース？
889 名前：823 mailto:sage [05/01/24 12:14:10 ]: >>878
> クラスベースの言語でも、無名クラスのような表現ができるのとできないのとがあるように、
> インスタンスベースの言語でも、こういう表現ができるのとできないのがあっていい。

もちろん、一般的な定義としてのインスタンスベースならば、その通り。

今議論しているのは、言語表現としてインスタンスベースあるいは
プロトタイプベースを定義するのならば、どういう基準になるのだろうか
という話。
890 名前：823 mailto:sage [05/01/24 12:15:31 ]: >>880
じゃ、rubyはインスタンスベース？
Smalltalkにもいくつかインスタンス毎にメソッド定義できる環境があったけど、
そういうのもインスタンスベース？
891 名前：デフォルトの名無しさん mailto:sage [05/01/24 12:26:13 ]: >>890
Rubyの特異メソッドはインスタンスに定義しているようにみせて、
実は特異クラスという見えない無名クラスに定義しています。
したがって、セマンティックス的にはクラスベースです。
シンタックス的にはインスタンスベースっぽいと言っても構わないでしょう。

Smalltalkの例もしかりです。とにかく、実質クラスにメソッドを定義
しなければならなければクラスベースです。
892 名前：デフォルトの名無しさん mailto:sage [05/01/24 12:49:09 ]: rubyだとクラスってオブジェクトの1種じゃなかったっけ
893 名前：デフォルトの名無しさん mailto:sage [05/01/24 13:01:00 ]: >>892
RubyもSmalltalkもクラスはまた別のクラスのインスタンスです。
Rubyは特異メソッドでクラスメソッドを“持っている”ように見えますが
これも特異クラスの暗黙の介在が必要です。したがって、こうしたクラスも
それ自体が自身で起動できるメソッドを持てているわけではないのです。
894 名前：823 mailto:sage [05/01/24 13:25:32 ]: >>891
> Smalltalkの例もしかりです。とにかく、実質クラスにメソッドを定義
> しなければならなければクラスベースです。

いや、Smalltalkの例の場合には、インスタンスにスクリプトをつけられる環境で、
それは無名クラスではなく、インスタンスがスクリプトのメソッド辞書を持っていた。

また、pythonの場合には特異クラスではなく、これまたオブジェクトのスロットに
直接バインドできる。

rubyはよく知らん。
895 名前：デフォルトの名無しさん mailto:sage [05/01/24 15:34:14 ]: >>894
インスタンスにメソッドをバインドできても、それを起動するための
しくみをクラスに仕込まなければならないならば、結局は同じことです。
繰り返しになりますが、そうした機構をもってインスタンスベース的と
宣伝するぶんには差し支えないと思います。

Pythonにはインスタンスベースの素養が十分あると言って良いと思います。
896 名前：823 mailto:sage [05/01/24 15:47:59 ]: >>895
> インスタンスにメソッドをバインドできても、それを起動するための
> しくみをクラスに仕込まなければならないならば、結局は同じことです。

いや、スクリプトを書く側にとっては、クラスに一切の変更を加えることなく
新しいメソッドを追加できた。
897 名前：デフォルトの名無しさん mailto:sage [05/01/24 16:39:29 ]: >>896
ですから、くどいようだけどそれはRubyの特異メソッドと同じこと。
ユーザーは特異メソッドを使うにあたって特異クラスを意識する
必要は必ずしもないわけだから。ユーザーがクラスの介在を意識しないで
済んでしまうような計らいがあるとき、それはインスタンスベースだと
言い切るのなら、それはそれで構わないと思う。ただ、無用な議論を避ける
ために、但し書きは必要でしょうけど。

「自分はシンタックスにおいてインスタンスベースなら、それの言語・
処理系はインスタンスベースだと解釈する立場だ」…とかね。
898 名前：823 mailto:sage [05/01/24 16:45:36 ]: >>897
> 「自分はシンタックスにおいてインスタンスベースなら、それの言語・
> 処理系はインスタンスベースだと解釈する立場だ」…とかね。

いや、俺の立場がどうこうという問題じゃなくて、
今議論しているのは言語表現上(syntaxだけではなく、constructsの問題)で
クラスベースとインスタンスベース(あるいはプロトタイプベース)を区別する
基準はできないだろうか、という話なんだが。

できれば>>822あたりからの流れを読んでもらえると助かる。
899 名前：デフォルトの名無しさん mailto:sage [05/01/24 17:26:08 ]: 結局、
　クラスを用いてオブジェクト生成に重みを置くなら「クラスベース」
　クラスを用いないオブジェクト生成に重みを置くなら「インスタンスベース」
で良いんじゃない？

クラスからのオブジェクト生成後の変更可能性は生成になんら関わらないし、
インスタンスベースが“クラス”オブジェクトを持っていてはいけないという規定も無いし。

自称･他称が違うこともあるだろうが仕様が無い。
900 名前：デフォルトの名無しさん mailto:sage [05/01/24 20:18:54 ]: んで、インスタンスベースのうち、プロトタイプチェーンを持っているのが
「プロトタイプベース」?
プロトタイプへの参照を持たず、いっそcloneもできないインスタンスベースの
言語って考えられないわけじゃないよね。現実にあるかどうかは知らんけど。
901 名前：デフォルトの名無しさん mailto:sage [05/01/24 21:46:36 ]: C言語でオブジェクト指向するかの様に、
インスタンスベースやプロトタイプベースでクラス指向する、
って言い方もできるわけだよな。
構文糖衣の差や、クラスの探索等を組み込みでやるか、
自力でやるか程度の違い。
どこで線引きするかなんて個人の解釈でしかない。
この議論は無意味だ。
902 名前：1 mailto:sage [05/01/24 22:07:56 ]: >>901
あなたにとって無意味かもしれないけど少なくとも私にとっては無意味じゃありませんね。
「プロトタイプベース」「インスタンスベース」についてはこのスレを見てもわかるように
言葉の定義がまだはっきりしていません。
（誰かが定義したしないという話ではなく広く一般に知れ渡った定義がはっきりしていないということ）
それを手探りで徐々に輪郭を作っていく議論は有益だと思いますよ。
ちょっと発散気味かもしれませんけど。
903 名前：デフォルトの名無しさん mailto:sage [05/01/24 22:36:01 ]: なんでプロトタイプベース言語作った作者に聞かないんだろう・・
904 名前：デフォルトの名無しさん mailto:sage [05/01/24 22:38:50 ]: >>902
いや、901が言いたいのは、823が言う言語表現なんてどうとでもなる
から、そこでの線引きについて議論することは無意味だってことだろ？
905 名前：1 mailto:sage [05/01/24 22:51:04 ]: ちょっとまとめてみました。

815 「クラスの有無」
オブジェクトがクラスに委譲せずに起動可能なメソッドを持てるかどうか
メッセージ送信の実行機構による分類(852)
クラスベースで、インスタンスが自前の
メソッドや属性を自由にできない…という制約をといたのが、インスタンスベース(880)
とにかく、実質クラスにメソッドを定義しなければならなければクラスベース(891)
クラスもそれ自体が自身で起動できるメソッドを持てているわけではないのです(892)
インスタンスにメソッドをバインドできても、それを起動するための
しくみをクラスに仕込まなければならないならば、結局は同じことです(895)
クラスが存在する時点でクラスベースとおもわれ(888)

818 「実行時にオブジェクトが定義されるか」
実行前にオブジェクトの挙動が決定されるかどうか
クラスをコードとして記述できるかどうかの意味(820)
「記述できるインスタンス」と「記述できないクラス」は存在しない(833)
『実行時、今まさに作られるのならば』インスタンスベース
オブジェクトを生成する為の“メタオブジェクト”と呼べるものが
『既に作られていたのならば』クラスベース (857)
906 名前：2 mailto:sage [05/01/24 22:51:34 ]: 822 「ソース上のプリミティブな要素」
ソース上のプリミティブな要素がクラスなのかインスタンスなのか
実行機構および言語機能による分類ではなく、言語表現による分類(823)

827 「オブジェクトのリテラル表記の可否」
任意のオブジェクトを1つのリテラル表現として記述できるかどうか
言語表現による分類(852)
Javaの無名クラスはあくまでクラス
それをインスタンスに対してできてこそのインスタンスベース(856)
実行時に生成されるかコンパイル時に定数として生成されるかで振舞いが変わるかな？(861)
無名だろうとクラスにメソッドを定義しないといけないのならクラスベース(867)
ユーザーがクラスの介在を意識しないで済んでしまうような計らいがあるとき、
それはインスタンスベースだと言い切るのなら、それはそれで構わないと思う。
ただ、無用な議論を避けるために、但し書きは必要(897)

899 「直交するものではないので重みづけで判断」
クラスを用いてオブジェクト生成に重みを置くなら「クラスベース」
クラスを用いないオブジェクト生成に重みを置くなら「インスタンスベース」
クラスからのオブジェクト生成後の変更可能性は生成になんら関わらないし、
インスタンスベースが“クラス”オブジェクトを持っていてはいけないという規定も無いし。
907 名前：3 mailto:sage [05/01/24 22:52:11 ]: 862(827派生) 「インスタンスベース≠プロトタイプベース」
インスタンスベースとプロトタイプベースを区別したほうがいいのかも
インスタンスベースだからといってプロトタイプという概念が必然かどうか(887)
インスタンスベースのうち、プロトタイプチェーンを持っているのが「プロトタイプベース」？(900)

865 「インスタンスベース＝プロトタイプベース」
プロトタイプベースとインスタンスベースとオブジェクトベースは同じものの別の呼び名です
自説大事に生粋のインスタンスベースを例外扱いかよ。 (864)
クラスベースの言語でも、無名クラスのような表現ができるのとできないのとがあるように、
インスタンスベースの言語でも、こういう表現ができるのとできないのがあっていい。 (878)
プロトタイプベースというと、プロトタイプの複製でオブジェクトを生じさせること
やプロトタイプチェーンによる委譲といった、特徴だけど、本質ではないところ
のみ取りあげて、やたらクラスベースと対比させたがる人が多いので困ります。 (881)

885(865派生) 「プロトタイプベースと呼ぶのはやめよう」
プロトタイプの語感からくる間違った認識で議論されるのは困ると思う。
だからインスタンスベースかオブジェクトベースと呼ぼう！
908 名前：デフォルトの名無しさん mailto:sage [05/01/24 22:53:48 ]: >>903
えーと。そのプロトタイプベースの言語を最初に作った当人が、クラスベースのアンチを
意識して、本質じゃないところを強調しちゃったもんだから、ややこしいことになっている
わけ。で、あとで客観的に分析して本質を突いてくれた本もあるんだけど、これが洋書で
高いから、誰も読んでないとくる。当然、インスタンスベースとかオブジェクトベースっても
通じやしないし、再三プロトタイプベースの別の呼び名だと言っているそばから、俺定義
をはじめるバカもいるってな始末でどーしようもない状態なのよ。
909 名前：デフォルトの名無しさん mailto:sage [05/01/24 23:00:48 ]: 日本の、こんなスレの片隅で再定義してどうすんだよ
910 名前：1 mailto:sage [05/01/24 23:11:24 ]: >>909
まぁそれもそうだけど、ここに書き込んでいる人は私含めて権威ある定義を知らないので
話が噛み合わなかったりしてはっきりさせたいってのがあるのではないかと。

>>908
その本読んでいるのだったら何が本質と書かれていたか教えて欲しいです。

>>904
901の「この議論」が指しているものが何かレスからは厳密に読み取れないのでなんとも･･･
823定義が独走しちゃっている感は確かにありますけどね。
911 名前：1 mailto:sage [05/01/24 23:16:03 ]: オフトピですが次スレのスレタイはどうしましょうか。

・プロトタイプベース
・インスタンスベース
・オブジェクトベース
912 名前：デフォルトの名無しさん mailto:sage [05/01/25 00:55:19 ]: 「インスタンスベース」
だけは、言葉に対するセンスが無いと思う。
913 名前：デフォルトの名無しさん mailto:sage [05/01/25 01:34:30 ]: >>912
なぜ？
プロトタイプベースは限定的なイメージを持たせがちだし、
オブジェクトベースはオブジェクト指向と混同しがち。
インスタンスベースなら、クラスとの背反という間違った発想を払拭してくれる
語感と併せて、よい落としどころだ思うけど。

けれど、プロトタイプベースで探してくる人が多いと思うから、今と同じ
プロトタイプベース・オブジェクト指向 2でいいんでないの？　>>1に但し書き入れて。
914 名前：デフォルトの名無しさん mailto:sage [05/01/25 01:45:19 ]: インスタンスの定義はクラスから生み出されるオブジェクト、ですけど
915 名前：デフォルトの名無しさん mailto:sage [05/01/25 01:46:01 ]: >>913
instanceって言葉のの意味解ってる？
916 名前：言っとくけど823じゃないよ mailto:sage [05/01/25 05:18:08 ]: >>908
> 当然、インスタンスベースとかオブジェクトベースっても
> 通じやしないし、

このスレじゃ十分以上に通じてるじゃん(藁

> 再三プロトタイプベースの別の呼び名だと言っているそばから、俺定義
> をはじめるバカもいるってな始末でどーしようもない状態なのよ。

そいつ、再三にわたって「本来の定義は置いておいて、言語表現上のconstructs
から分類するとしたらどういう分類がありうるか、という議論をしている」と
いうようなことを言ってなかったか？

その議論に割り込んで「別の呼び名だ、馬鹿」と、マトハズレな痴態を晒す
マヌケもいるって始末でどーしようもない状態になったわけ。

しかも、constructsをsyntax sugarで覆えるわけないのにsyntax sugarだとか
言ってる大馬鹿もいるしでもう爆笑するしかないね。
917 名前：デフォルトの名無しさん mailto:sage [05/01/25 10:40:43 ]: >>914,915
「インスタンスベース」への受け入れ方で、その理解度がはっきりと
分かるというのはなかなかおもしろい効能だ。
918 名前：デフォルトの名無しさん mailto:sage [05/01/25 11:34:59 ]: >>908
その高い本の書籍名とISBN番号希望！

昔は洋書読まなかったんだけどAmazonができてから良く読む用になったんよ、
良い本あれば元値にはこだわらないから教えてほしい。
（昔は入手が大変だったのと$1 = \130の頃でも２００円換算とかされてとても買う気になれんかった）
919 名前：デフォルトの名無しさん mailto:sage [05/01/25 12:14:18 ]: >>916
定義もおぼつかない状態で言語表現上の構造概念を論じること
は可能なの？
920 名前：デフォルトの名無しさん mailto:sage [05/01/25 13:40:28 ]: >>919
> 定義もおぼつかない状態で言語表現上の構造概念を論じること
> は可能なの？

言語表現上の構造や概念から定義しようという議論であることがまだ理解できない？
921 名前：デフォルトの名無しさん mailto:sage [05/01/25 15:48:43 ]: >>918
0387947752
922 名前：デフォルトの名無しさん mailto:sage [05/01/25 17:54:48 ]: A Theory of Objectsだね？
ありがとん。
923 名前：デフォルトの名無しさん [05/01/25 18:28:44 ]: >>913
プロトタイプ言語のクラスレスなオブジェクトはinstance っていう言葉の持つ自然な意味と
全く合致していない（むしろ対立している）から「インスタンスベース」っていう言葉はまずいでしょ。

英語としての言葉の意味なんてどうでもいいっていうなら、メソッドベースでもフレームベースでも
moon base でも何でもいいじゃん。
924 名前：デフォルトの名無しさん mailto:sage [05/01/25 19:25:03 ]: >>923
moon base は如何なものか。
せめて white b(ry
925 名前：デフォルトの名無しさん mailto:sage [05/01/25 20:06:44 ]: >>923
謎のの方か？、アルファの方か？、これで年齢が一回りは異なる訳であるが。
926 名前：デフォルトの名無しさん mailto:sage [05/01/25 21:10:27 ]: オブジェクトベース言語に「クラスがない」なんてのは常識の嘘。
そんなことにこだわっていると、かえって本質の理解を妨げるよ。
927 名前：デフォルトの名無しさん mailto:sage [05/01/25 22:08:55 ]: >>921は親切で教えてあげたのだろうが、これじゃひろゆきがしかけた
「電話番号張り付け検出スクリプト」にひっかかって警察に通報されてそうだ。
928 名前：デフォルトの名無しさん mailto:sage [05/01/25 22:17:33 ]: 英語に疎いので辞書を引きました。
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言語を
指してしまいそうだし、
「プロトタイプベース」では、もしプロトタイプチェーンを持たないような
言語があったら困る。

さあ困った。
929 名前：デフォルトの名無しさん mailto:sage [05/01/25 22:22:40 ]: >>921
AmazonのURLはISBN番号を含んでいる事をたった今知りました。

A Theory of Objects (Monographs in Computer Science)
www.amazon.co.jp/exec/obidos/ASIN/0387947752/
930 名前：デフォルトの名無しさん mailto:sage [05/01/26 00:03:48 ]: 7000円は流石に高すぎる
931 名前：デフォルトの名無しさん mailto:sage [05/01/26 00:16:53 ]: >>930
Gemsの原書もそんなものだし、普通じゃないかな？
932 名前：デフォルトの名無しさん mailto:sage [05/01/26 00:24:02 ]: プロトタイプベースを感じとりたいくらいで手を出せる本じゃないな。
933 名前：デフォルトの名無しさん mailto:sage [05/01/26 00:26:38 ]: >>932
そんだけだったら俺も手はださんだろうけど、専門書だったら普通じゃないか？
俺は技術書系の活字中毒だからなぁ、このくらいの値段の本だと年に１０冊じゃ効かないかも。

＃金がないときゃ図書館にお願いするが。
934 名前：デフォルトの名無しさん mailto:sage [05/01/26 22:53:50 ]: >>921
この書込にはおそらく電話番号書込自動警察通報システムが働いた
935 名前：デフォルトの名無しさん mailto:sage [05/01/26 23:00:22 ]: >>934
でも03でこの長さは電話番号じゃないからなぁ。
936 名前：デフォルトの名無しさん mailto:sage [05/01/27 11:27:26 ]: >>935
03-8xxx はないよね。3xxx と 5xxx だけ？
937 名前：デフォルトの名無しさん mailto:sage [05/01/28 13:55:03 ]: よく分かっていない人たちによる
よく分かっていないものに対する
たぶん、こんなもんだろうという
言語表現上の定義、まだぁ？
938 名前：デフォルトの名無しさん mailto:sage [05/01/29 11:35:28 ]: >925
SHADOだろ（ｗ
939 名前：デフォルトの名無しさん mailto:sage [05/01/29 13:10:49 ]: >>938
制作はどっちもITCなんだがなぁ、１０年以上の開きがあるんだよなぁ。
コーニッグ司令官とストレイカー長官じゃ。
940 名前：デフォルトの名無しさん mailto:sage [05/01/29 14:54:02 ]: 粘着の発生により、誰もいなくなりました。

＝＝＝＝＝＝＝＝　終　了　＝＝＝＝＝＝＝＝＝
941 名前：デフォルトの名無しさん [05/02/03 20:37:55 ]: 定義の話なんてやめればいいだけ
942 名前：Javaのスイッチ文のように作用し、 mailto:sageそのタグ内で幾つかの候補を選択することになる。 [05/02/03 20:55:50 ]: だな。
943 名前：デフォルトの名無しさん mailto:sage [05/02/07 19:49:57 ]: Methodの呼び出しを効率よくJIT化ってできないもんでしょうか？
単純にテーブル生成するとメモリ食ってヒドイ目に遭うんです。
944 名前：デフォルトの名無しさん mailto:sage [05/02/11 01:27:14 ]: >>943
Methodの呼び出し部分をJIT化して効率よくなるってことは、
呼び出されるMethodの方は、当然JITコンパイルされてるんだよね?
945 名前：デフォルトの名無しさん mailto:sage [05/02/11 02:24:20 ]: >>943
CPUの分岐予測みたいに以前のメソッド呼び出しだけを保存しておいて、
次回の関連オブジェクトの状態も不変なら＜抽象的でごめん
そのままコール、だめならもっと上位の定義から辿る。

以上素人考え……遅そう。

>>944
たぶんCPUのキャッシュ効率を考えてるんじゃないかな。
946 名前：デフォルトの名無しさん mailto:sage [05/02/18 23:32:39 ]: ECMAScript 関連で参考になるサイト。
Effective JavaScript（ttp://www.interq.or.jp/student/exeal/dss/ejs/）
JavaScript 深層（ttp://www.hawk.34sp.com/stdpls/jsnotes/jssinso/）
結構当てになると思うけどどうよ？
947 名前：デフォルトの名無しさん mailto:sage [05/02/19 00:43:20 ]: 別に
948 名前：デフォルトの名無しさん mailto:sage [05/02/20 18:31:11 ]: というか全然
949 名前：デフォルトの名無しさん mailto:sage [05/02/20 18:32:35 ]: >>947-948
殺してやる
950 名前：デフォルトの名無しさん mailto:sage [05/02/20 18:33:38 ]: >>949
殺して姦る
951 名前：デフォルトの名無しさん mailto:sage [05/02/20 21:12:37 ]: >>947
>>948
どの辺が？
952 名前：デフォルトの名無しさん [05/02/22 23:39:31 ]: 今作ってる俺言語に、プロトタイプベース(オブジェクトベース?)風のOOの
機能を盛り込もうとしています。

言語そのものは、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じゃねえ、とか、それじゃ実装できんだろ、とか、
気が付くところがあったら教えてくださいませ。
# プロトタイプチェーンはもちょっと後で考えるつもり。
953 名前：デフォルトの名無しさん [05/02/23 08:32:12 ]: o.hogeに関数を設定するのと関数の返り値を代入するのはどう書き分けるの
954 名前：デフォルトの名無しさん mailto:sage [05/02/23 09:11:38 ]: >>953
普通に{...}があるかないかじゃダメなのか？
955 名前：デフォルトの名無しさん mailto:sage [05/02/23 11:49:56 ]: >>953
functionって関数名じゃなくて関数宣言の予約語じゃないの？
956 名前：デフォルトの名無しさん mailto:sage [05/02/23 14:21:33 ]: WEB制作板にカエレ
957 名前：952 mailto:sage [05/02/24 00:23:25 ]: >>953-955
反応ありがとう。

>>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が必要
}

関数のネストは今のところ考えてないので、スコープは、
・グローバル
・関数内ローカル
・ネストした分のクロージャ
になるんじゃないかと思ってます。
958 名前：デフォルトの名無しさん [05/02/24 10:45:47 ]: プロトタイプ・チェーンの無いものはプロトタイプベース・オブジェクト指向言語と呼ぶべきでない、
みたいな議論、どーでもいい話で盛り上がってるっぽくてﾜﾗﾀ

そんなん、プロトタイプとなるインスタンスへの委譲がなくとも、
インスタンスをプロトタイプとして新しいインスタンスを作るんだから、プロトタイプ～でええやん。

こーゆーつまらん議論を喧喧ｶﾞｸｶﾞｸやって、しまいには辞書まで引っ張り出してくるのって、
きっと（ｒｙ
959 名前：デフォルトの名無しさん [05/02/24 10:55:24 ]: 一見意味がありそうで、実はとってつけたどーでもいい話を延々するのは、文系人間のﾋﾞｮｰｷだな
960 名前：デフォルトの名無しさん mailto:sage [05/02/24 22:08:44 ]: >>958
そーゆーつまらん議論はとっくに終わっているのに、わざわざほじくりだして
しかもageるのって、きっと(ry
961 名前：デフォルトの名無しさん [05/02/27 12:58:24 ]: そして誰もいなくなったらしい…
1000目前でこれは悲しいので、一応ageとく。

次スレはいらないの?
962 名前：デフォルトの名無しさん mailto:sage [05/02/27 15:26:12 ]: >>961
ノ
963 名前：デフォルトの名無しさん [05/02/27 15:29:24 ]: 次スレは、「POO総合スレ」的なのがいいな。
964 名前：デフォルトの名無しさん mailto:sage [05/02/27 21:56:44 ]: タイトルにインスタンスベースも入れて欲しい。
965 名前：デフォルトの名無しさん mailto:sage [05/02/27 22:52:20 ]: このスレは
頭が痛くなるだけで
何も生み出さない
次スレは*無し*の方向で
966 名前：デフォルトの名無しさん mailto:sage [05/02/28 00:24:42 ]: >>965
あんたの頭が足りないのをスレのせいにされてもなあ…
上のほうには有意義な議論もあったろうに。
967 名前：デフォルトの名無しさん mailto:sage [05/02/28 01:09:09 ]: 有意義か？ｗｗｗ
結局ここに書き込んでる奴は、何がしたいわけ？
>>3-4みたいなマイナー言語並べて各自の勝手な解釈で
分類の仕方に終始してるだけというか。
何が有意義なのかねえ・・
言語ごとに専用スレ立てれば？
968 名前：デフォルトの名無しさん mailto:sage [05/02/28 02:02:03 ]: ファビョるなよ低脳…。合わないならこんなスレ来ないで、
HSPスレなりマ板なりどこでも逝けばいいだろうに。
969 名前：デフォルトの名無しさん mailto:sage [05/02/28 02:49:29 ]: うわｗｗ
合う合わないの話なんてしてないのに。
自分が低脳だとは考えたことが無いんだろうね。
痛すぎるよ、君。
970 名前：デフォルトの名無しさん mailto:sage [05/02/28 08:39:01 ]: >>969
すげえ。本物の低脳だ。
971 名前：デフォルトの名無しさん mailto:sage [05/02/28 19:33:03 ]: Rubyこそ最高言語
972 名前：デフォルトの名無しさん mailto:sage [05/02/28 19:43:12 ]: >>971
すげえ。本物の低脳だ。
973 名前：デフォルトの名無しさん [05/03/01 01:31:10 ]: 　で、低脳は放置するとして、次スレはどうするよ?

>>964
　「インスタンスベース」という言葉は一般に使われていない上に、
英語としても変(>>928)だから、却下されるべきだと思うよ。

　俺としちゃ、プロトタイプOOな言語が具体的にどういう時に役に立つのか、
もうちょっと色々話を聞きたいと思ってる。
　>>133のリンク先にある話は割とわかるんだが、200～あたりで話されている、
「プロトタイピングで便利」というのは納得しかねるなあ。動かしながらいじるのが
便利だとして、具体的にどこをどういじりたいんだろう?
974 名前：デフォルトの名無しさん mailto:sage [05/03/01 04:04:25 ]: 自分が低脳だとは考えたことが無い低脳は放置するとして、次スレは無しの方向で。
975 名前：デフォルトの名無しさん mailto:sage [05/03/01 10:11:19 ]: 自ら“英語に疎い”と認めつつ、実際に動詞としての使用例で以って
“だとすると「インスタンスベース」はまずいね”と仰ってしまう >>928 は
果たして参考になるのだろうか…？
976 名前：デフォルトの名無しさん mailto:sage [05/03/01 10:54:04 ]: >>975
意味をよく掴めなかったので、つっこみつつ質問。

> 自ら“英語に疎い”と認めつつ、実際に動詞としての使用例で以って

疎い思っているからこそ(失礼、>>928さん)、辞書をひいたのでしょう。
確固とした情報源を使うことで、(変な論理で話を変な方向に展開させなければ)
信頼できる情報となり得るのではないでしょうか。

まさか、「英語に疎い人が辞書を使っても、信頼なんかできないよ」
という意味ではないですよね？
977 名前：デフォルトの名無しさん mailto:sage [05/03/01 11:48:39 ]: できないよ。ｗ
978 名前：デフォルトの名無しさん mailto:sage [05/03/01 12:11:19 ]: まあ「インスタンスベース」はある種、ちょっとイジワルな踏み絵ですね。
嫌悪感を示す人の中で、このパラダイム向け言語処理系をある程度、
まともに使ったことがある人は皆無に近いと思いますよ。
批判的になることで、自ら、その事実を晒してしまっているわけです。
979 名前：デフォルトの名無しさん mailto:sage [05/03/01 12:33:35 ]: >>978
> 嫌悪感を示す人の中で、このパラダイム向け言語処理系をある程度、
> まともに使ったことがある人は皆無に近いと思いますよ。

ポカーン
英語的に問題あるという話なのに、978は一体何を考えているのでしょうか？
980 名前：デフォルトの名無しさん [05/03/01 12:36:49 ]: こーゆーつまらん議論を喧喧ｶﾞｸｶﾞｸやって、しまいには辞書まで引っ張り出してくるのって、
きっと（ｒｙ
981 名前：デフォルトの名無しさん mailto:sage [05/03/01 16:52:31 ]: >>979
ん、英語的に問題？　問題があるのは928（と979）の理解のほうだろ。
インスタンスが「クラスのインスタンス」のコンテキストを意味するのは
自明のことだし、インスタンスベースがオブジェクトベースの同義である
ことはインスタンスがオブジェクトと同義である程度には許されるはずだ。

そして、このパラダイムに則って運用される世の中のオブジェクトのほと
んどが実質、何らかのクラスに属している。つまり、当初、取りざたされ
たようなクラスの有無は、このパラダイムにおいて本質じゃない。

お前みたいのが分かったふりして出てくるのを助長するからプロトタイプ
ベースってのは限定的でマズいって話。これだけ繰り返しても、まだ分か
らないのか？
982 名前：デフォルトの名無しさん mailto:sage [05/03/01 18:33:18 ]: ＞インスタンスが「クラスのインスタンス」のコンテキストを意味するのは自明のことだし

自明じゃないだろ。
「クラスのインスタンス」と自分で自明じゃない事を証明してしまってるじゃないか。
アフォか。
983 名前：デフォルトの名無しさん mailto:sage [05/03/01 18:55:58 ]: >>982
悪かった。このスレ以外では…、と但し書きを入れるのを忘れてたよ。orz
984 名前：デフォルトの名無しさん mailto:sage [05/03/02 00:08:18 ]: インスタンスベースなんて、おかしな用語を広めようとしているのは
何を目的としているのだろう。

英語の文献では、prototype basedもしくはclone basedくらいしか
使われていない。英語の意味的にもinstance basedは有り得ない
のだから、変な用語を広めようとするのは止めてくれ。
985 名前：デフォルトの名無しさん mailto:sage [05/03/02 01:18:58 ]: >>984
どんな文献を読んで言っているんだか…。文献調査が足りてないぞ、学生君。
とりあえず、手近な文献データベースでinstance-based AND object-orientedな
検索かけてみたまえ。話はそれからだ。
986 名前：デフォルトの名無しさん mailto:sage [05/03/02 01:33:06 ]: instance-based ：実例を基本とした
987 名前：デフォルトの名無しさん mailto:sage [05/03/02 04:14:22 ]: >>981
> インスタンスが「クラスのインスタンス」のコンテキストを意味するのは
> 自明のことだし、インスタンスベースがオブジェクトベースの同義である
> ことはインスタンスがオブジェクトと同義である程度には許されるはずだ。

じゃ、その定義によるとSmalltalkはインスタンスベースだな。プゲラ
988 名前：デフォルトの名無しさん mailto:sage [05/03/02 08:18:56 ]: >>985
検索にヒットしたらそれが正しい用語だと思っているのか？
instance-basedとobject-orientedの両方が含まれているだけの文章が
山程ヒットしているだけで、無関係のものしかないようだが？

ここ10年くらいのまともなプログラミング言語系journal、proceedingsや
それ以前の主要な文献でinstance-basedなんて言葉をいわゆる
プロトタイプベースの意味で使ったものなんか見たこと無いぞ。
989 名前：デフォルトの名無しさん mailto:sage [05/03/02 11:22:27 ]: >>988
> instance-basedなんて言葉をいわゆる
> プロトタイプベースの意味で使ったものなんか見たこと無い

へえ…

portal.acm.org/citation.cfm?id=312023
portal.acm.org/citation.cfm?id=141955
portal.acm.org/citation.cfm?id=84459
portal.acm.org/citation.cfm?id=323737
...
990 名前：デフォルトの名無しさん mailto:sage [05/03/02 18:16:37 ]: Rubyですべて解決！！！！！！！！！！！１１１１１１１１１１１
991 名前：デフォルトの名無しさん mailto:sage [05/03/02 19:09:54 ]: い
992 名前：デフォルトの名無しさん mailto:sage [05/03/02 19:30:32 ]: ん
993 名前：デフォルトの名無しさん mailto:sage [05/03/02 19:44:40 ]: nullpo
994 名前：デフォルトの名無しさん mailto:sage [05/03/02 19:53:40 ]: ら
995 名前：デフォルトの名無しさん mailto:sage [05/03/02 19:56:12 ]: ん
996 名前：デフォルトの名無しさん mailto:sage [05/03/02 19:59:41 ]: 女
997 名前：デフォルトの名無しさん mailto:sage [05/03/02 20:01:39 ]: ハ
｜
ト
マ
ン
教
998 名前：デフォルトの名無しさん mailto:sage [05/03/02 20:03:28 ]: 　　　　　./　　　　　　 ;ヽ
　　　　　 l　　＿,,,,,,,,＿,;;;;i　＜いいぞ　ベイべー！
999 名前：デフォルトの名無しさん mailto:sage [05/03/02 20:04:09 ]: フ
ゥ
ハ
ハ
ハ
｜
ハ
ァ
｜
1000 名前：デフォルトの名無しさん mailto:sage [05/03/02 20:04:20 ]: nextThread = [ self clone ];
1001 名前：１００１ [Over 1000 Thread]: このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef