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

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