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

1 名前：デフォルトの名無しさん [03/12/08 21:30] オブジェクトを複製または継承によって生成を行う言語， プロトタイプベース・オブジェクト指向言語について語りましょうよ． 関連リンク >>2 175 名前：デフォルトの名無しさん mailto:sage [04/01/26 00:35] >>174 クラス定義を動的に変えられることは、仕様の変更を伴うものばかりとは 限りません。メソッド名を変えずに、別のより性能の良いアルゴリズムを 採用したものに差し替えるとか、それこそバグの修正ということもありえます。 大事なのは、システム(アプリ)を停止せずにこれができるということで、 クラスのあるべき立場を危うくすることは目的ではないと思います。Smalltalk にしても CLOS にしても、できるからといって、クラスの定義がどんどん 変わってゆくような設計は特殊な事情でもなければしないはずです。 176 名前：デフォルトの名無しさん mailto:sage [04/01/26 00:36] 171じゃないけど燃えてきたので横槍 >>173 Java の interface は、クラスの定義時に、設計者が 宣言しなければならないところが問題。 例えば、メソッド A と B と C を要求する interface I があるとしよう。そしてクラス X は A も B も C も定義 している。しかしクラス X が interface I を implements していなかったら I としては使えないわけだ。つまり、 クラスの作成者があらかじめあらゆる使われ方を考慮 しておかないといけない。でもこれは無理な話なわけで。 ここで動的型付け言語だとそもそもそういう宣言は必要なくて、 実行時に A B C というめそっどがあればよい。また、静的 型付け言語でも interface の後付けができる処理系が あったはず。そういう機構があるなら、>>171 の言ってる 問題点は解決したと言ってもいいと思うよ。 177 名前：デフォルトの名無しさん mailto:sage [04/01/26 00:44] >>175 >>152の > だから、変更のし難さというのはクラスベースだからというわけではなく、 > むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。 > つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と > 同一視したことによる縛り。 とうまく整合できないのですが、 よろしければ補足をいただけませんか？ 178 名前：デフォルトの名無しさん mailto:sage [04/01/26 01:01] 実行中に変えるということについては、型とかクラス云々ではなく、 実行中にプログラムを変える口を持つかどうかということではないだろうか。 179 名前：デフォルトの名無しさん [04/01/26 01:28] >>176 interface I をインターフェース継承して、Xをメンバに持つ新しいクラス newXを作ってメソッドA,B,CをXに委譲すれば解決。 180 名前：デフォルトの名無しさん mailto:sage [04/01/26 02:18] みんなクラスとかインターフェースとか、型付けとか好きだねぇ。 181 名前：デフォルトの名無しさん mailto:sage [04/01/26 02:38] >>179 それだと実行前に定義しておかなければならないという問題を全然解決していない。 182 名前：152 mailto:sage [04/01/26 04:24] >>177 私は>>175氏ではありませんが、たぶん彼が言いたいのは、 「納入したシステムが実行時に動的に自身のクラスを頻繁に変更するのは 特殊な場合だろう」 ということなのでは？ 一方、私の>>152は実行時といっても開発における実行時の話であり、 クラスを変更するのはプログラマです。 というわけで、私としては>>175氏との間に意見の齟齬は無いと思っています。 で、私自身、>>175氏に同意します。 Smalltalkで「実行時に動的に自身のクラスを頻繁に変更する」のも可能では ありますが、よほど強い要請がなければやりません。 ただ、それが可能であることは重要だと思います。 プロトタイプベースでも同様だと思います。 動的にdelegationを変更したりslotを変更するのは、それ自体が目的ではなく、 表現したい振舞いを簡潔かつ見通し良く記述するための手段に過ぎないわけで そのためのプロトタイプベースです。 実現したい振舞いを可能にするための動的変更を最小のインパクトに抑えるのは プロトタイプベースであれクラスベースであれ共通の指針だと思います。 この視点に立った上で、言語処理系自体が動的変更を標準の機能として認めていて 実際に簡潔な記述で動的変更が可能であることは強力な武器だと思っています。 183 名前：厨 mailto:sage [04/01/26 12:48] >>182 > 変更のし難さというのは > 静的型の弊害であり、 > クラスをそのまま型として使うことの弊害 つまり、クラスが静的型だから動的に変えられないよう、と。 で クラスを動的に変えるのは普通よくないよ。 ということなら、 クラスを静的に変えるときに、静的型うざいよう。 ということになると思うのですが 結局影響を受ける参照箇所は直さなきゃいけないんだから かわらなくないですか? 184 名前：デフォルトの名無しさん mailto:sage [04/01/26 17:22] >>183 > 結局影響を受ける参照箇所は直さなきゃいけないんだから もっと具体的に言わないと議論のネタにならないと思われ。 185 名前：デフォルトの名無しさん [04/01/26 18:40] 動的に変更できるかどうか、と静的型付けは関係ない、って ことじゃね？ 186 名前：デフォルトの名無しさん mailto:sage [04/01/26 18:51] 動的なのが一番だと思う人が多いんだろうけれど、 オブジェクトを動的に委譲でのみリンクしていく 言語だと規模が大きくなると設計とパフォーマンスの 両方ですぐに行き詰まると思う。 187 名前：CLOS mailto:sage [04/01/26 23:00] そこで俺の出番ですよ。クラスベースで型情報つかった最適化も やるけど、いざというときは Change-Class で変身できるし。 MOP つかえば抽象クラスやインターフェースも作れるよ！ 188 名前：デフォルトの名無しさん mailto:sage [04/01/26 23:51] >>183 クラスを動的に変えるのが良くないのは、ある程度仕様が固まってきてからでしょう。 開発初期にオブジェクトの振る舞いを動的に変更出来る事はメリットあると思うな。 私はシステム開発した事が無いので、的外れな事を言ってるかもしれないけど（一応 その周辺部で仕事はしてますが）。 この延長で、全く仕様が固まらない様な仕事、例えば研究者が全く新しい分野のソフト ウェアを作ろうとしたら? 或は、仕様の変更に柔軟に対応しなくてはいけないシステム だったら? ソフトウェア自身の速度よりも、ソフトウェアを開発するスピードが重要 だったら? そう言う場合は制約の少ない言語を選びたい人もいるのではないでしょうか? 逆に言えば、経理システムや在庫管理システム向きの言語ではないと思う。 スレの流れに沿ってなくてｽﾏｿ。 189 名前：188 mailto:sage [04/01/27 00:07] 何か、並のスクリプト言語を擁護してるみたいな文章になってしまいました。 一応、Kansas/Nebraska と Yahoo! Store, 書き捨てのスクリプトを念頭に 置いてます。 あと、病院のシステムを開発するのにも向いてないと思います。 190 名前：デフォルトの名無しさん mailto:sage [04/01/27 00:48] ずばりプロトタイプベースは何の開発に向いてますか？ 191 名前：デフォルトの名無しさん mailto:sage [04/01/27 01:42] >>186 それが問題となるのは、あなたが適用すべき言語の選択を間違った時ではないでしょうか。 それは置いておいても、Self は積極的な最適化で結構速いらしいですし、同じ動的言語の Common Lisp もネイティブコードにコンパイルする事でかなり速いです。 192 名前：デフォルトの名無しさん mailto:sage [04/01/27 17:27] >>191 うーむ、Java にはリフレクションというものがあって、クラス情報の分からない インスタンスのメソッドやフィールドにアクセスできるようになっている。 しかし、使うのは最低限にしろという原則がある。処理が重いから。 （どのぐらい重いのかは知らないけど） 動的な型付けの言語って、すべての局面でリフレクションをやっているような ものじゃないのかな？やっぱりどうしても比較すれば重くなるでしょ？ （このリフレクションという言葉が、本来の意味から大きく外れているのを知った 　のは最近…） 193 名前：CLOS mailto:sage [04/01/27 23:18] 静的な言語で無理やりなリフレクションするよりは速いかもしれないとは 考えつかないのかな？特に漏れなんてマルチメソッドディスパッチのおかげ で最悪メソッドコール毎にメソッドの探索が必要になっちゃうけどメソッド キャッシュやオプショナルな型指定のおかげでそこそこがんがれる。 まぁ、漏れも性能が大事な部分では「オプションで」型指定できたり、 メソッド内では引数の型指定で積極的な最適化が可能だったりと完全に 動的言語ってわけじゃないけどナー。普段は動的で、必要なときに 型を使うわけだ。ウマー。 194 名前：CLOS mailto:sage [04/01/28 00:22] おっと、プロトタイプスレだったな。実は Common Lisp 界でも CLOS みたいな クラスベースよりプロトタイプベースのほうが逝けてるゼ！とクラスベース vs プロトタイプベースの争いがあったんで完全にスレ違いってわけでもないのだ。 …と言い訳してみる。 195 名前：デフォルトの名無しさん mailto:sage [04/01/28 00:31] >192 Javaのリフレクションが重いというのは只の伝説です。 今のJVMなら、普通のメソッド呼び出しと殆ど変わりません。EJBなんてリフレクションだらけ。 最低限にしるというのは、コードの解り易さの為。 196 名前：デフォルトの名無しさん mailto:sage [04/01/28 00:44] なんのためのクラス階層なんだか 197 名前：デフォルトの名無しさん mailto:sage [04/01/28 00:53] >>196 どのレスに対して言ってるの？ 198 名前：192 mailto:sage [04/01/28 01:09] >>193-194 すると、こんな感じ？ Java = 静的な言語だけど、必要に応じて動的にも使える。 CLOS = 動的な言語だけど、必要に応じて静的にも使える。 最近は Java でも、ほとんどのコードはパフォーマンスを気にせずに書いて、 ロジックが完成してからパフォーマンス測定して、ボトルネックになってる 部分だけチューニング、というやり方が増えてきた。 そうすると、CLOS のやり方のほうが便利かも…。 >>195 ああ、そうなんだ！JSP のタグリブとかも、リフレクションの塊なわけで、 「こんなんで良いのかな？」と思ってたんだ。 昔の話だったのね。安心しますた。 199 名前：デフォルトの名無しさん mailto:sage [04/01/28 01:20] >.198 重くないといっても通常のに比べたら数倍はやっぱりかかる。 まあ昔みたいに何十倍もかからなくはなってるが。 200 名前：CLOS mailto:sage [04/01/28 01:29] まぁ、オプショナルな型というのは CLOS というより Lisp の伝統なんだがな。 Lisp マシンの頃からそうだった気がする。基本的にはさっさっと書いて、 プロファイリングして、型を間違ったらヤバそうなところとかボトルネックに あたりをつけて型指定を入れるスタイルだな。（性能＋型チェックのため） CLOS 自体は動的な側面が強く、オーバーヘッドを嫌った連中がプロトタイプベース ＋制約ベースの最適化なんてのを考えたりもしたわけだ。最近だと型にかぶれてたり 型推論を装備しちゃた変種まで表れて動的言語とはひとくくりにはできないがな…。 201 名前：デフォルトの名無しさん mailto:sage [04/01/28 04:04] 素朴な疑問なんだけど、このスレで Java にはとか Java でもとか言ってる中の人は Java 以外の言語知らないのかしらん? Sather ではとか言ってさらさらっとコードでも書いてくれたら ｶｺｲｲ のに。比較対象 が Java 以外にもあると良いな。 202 名前：デフォルトの名無しさん mailto:sage [04/01/28 04:11] このスレでSatherを出すことにそんな意味があるんですか？ 満たされるのはあなたの衒学趣味くらいではないですか？ 203 名前：デフォルトの名無しさん mailto:sage [04/01/28 04:52] strong typing な OO 言語の例として出したんだがまずかったかな。他は Eiffel と OCaml くらいしか知らんし。OCaml でオブジェクト指向している例は見たことが無いし、Eiffel なら Sather の方が面白そうかなと。後は Strongtalk とか? 色んな言語と比較した方が、 それぞれの関係性も理解出来ると思ったんだが。 204 名前：デフォルトの名無しさん mailto:sage [04/01/28 05:15] プロトタイプのカウンターとして、より多くの人がスレに参加できるJava以外に他の言語が 出てくる必要があるのは、Javaにはない機能や概念に触れた内容のレスである思います。 あなたの真の欲求は、「マイナー言語知識自慢スレ」を立ててそこで満たしてください。 もちろん、このスレで知識を生かしたこのスレの趣旨にあう良レスをしてくれることはみんな歓迎するでしょう。 205 名前：デフォルトの名無しさん mailto:sage [04/01/28 05:35] でもさ、Java な人って議論が設計方面に偏る傾向が無い? 言語の実装とか、言語が備えるべき 機能は何かとか、そういう視点があっても良いと思うんだよね。マイナー言語と片付けるのも 反対はしないけど、それを言ったらプロトタイプベース言語はどうなんだろう。必要な言語に だけ触れていれば良いの? 206 名前：デフォルトの名無しさん mailto:sage [04/01/28 13:00] 私はJava な人の一人です。 私が Java の話しかしないのは、恥ずかしながら「それしか知らない」から。 言語が備えるべき機能についても、Java の機能しか知らないから、他のことが 言えないんす。 このスレに来てるのは、必ずしも Java に満足していなくて、別の可能性を 知りたいからなんす。プロトタイプベースには昔から興味があったし。 設計方面に片寄った話をするのは、実際、そこで困っているから。Java 以外の 可能性に触れることで、それを解決できたら、と思ってます。 あわよくば、Java での仕事に、その言語の考え方を取り入れられたらいいなあ。 デザインパターンやリファクタリングが Smalltalk から取り入れられたように。 まあ、Java な人がみんな、私みたいな厨房というわけではないと思いますが。 207 名前：デフォルトの名無しさん mailto:sage [04/01/28 13:27] Javaしか知らないって奴が出張ってきてもな。 他を自主的に覚えようとしない訳だしな・・。 ここは206の疑問に答えるスレでもないし とりあえずSmalltalkでも勉強したら？ 208 名前：デフォルトの名無しさん mailto:sage [04/01/28 13:39] 随分と排他的やね。 209 名前：デフォルトの名無しさん [04/01/28 15:46] ISLISP が最高です。 210 名前：デフォルトの名無しさん mailto:sage [04/01/28 17:56] 自分がそのレスに適切と思った言語で書けばよろし。 211 名前：デフォルトの名無しさん mailto:sage [04/01/28 22:21] ところでプロトタイプベース言語を母語として活用している人っているのかな? 今やるなら io が結構良さげな感じがするんだけど、こういう便利な使い方があるぜ ってのがあったら教えて欲しい。 212 名前：デフォルトの名無しさん mailto:sage [04/01/28 22:34] ここは質問スレではありません 213 名前：デフォルトの名無しさん mailto:sage [04/01/28 23:22] 無いから流行ってないんです。 214 名前：デフォルトの名無しさん mailto:sage [04/01/28 23:40] Javaな人とかC++な人ってのは仕事でプログラミングしてる人が多いのだろうから アカデミックな事にはあまり興味無い実務屋が多いんでしょう 仕事でJavaと付き合ってるのでプライベートでは他の言語とお付き合いしたいという 私みたいなのもいるけど ちょっと調べたけどJavaScriptってかっこいいなあ。 結構ちゃんとしたプロトタイプベースのOOPLなのね。 私にとってはSmalltalk並にヒット。 215 名前：デフォルトの名無しさん mailto:sage [04/01/28 23:42] >>214 漏れはJavaScriptでクラスを使いたいYo! 216 名前：デフォルトの名無しさん [04/01/29 04:43] 色んな嗜好があるもんだな。 217 名前：デフォルトの名無しさん mailto:sage [04/01/29 13:17] ザッと過去ログ読んでみたけど、プロトタイプベースにするメリットが良く分からなかった。 218 名前：デフォルトの名無しさん mailto:sage [04/01/29 13:19] そりゃ実用志向のスレじゃないからね。 219 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:25] Traits squab.no-ip.com:8080/wiki/818 > (Traitsを) JavaScript ではまんまクラスと呼んでいる。 JavaScriptでクラスなんて呼ばれるものはあったっけ？ コンストラクタのこと？ 確かに、 var a = new String("hoge"); alert(a instanceof String); //true と表示。 という動作を見ると、一見、クラスっぽい。 220 名前：デフォルトの名無しさん mailto:sage [04/01/30 02:44] >>214 今時C++つついてる奴も結構趣味に走ってると思うが。特にtemplate方面。 221 名前：デフォルトの名無しさん mailto:sage [04/01/30 09:28] >>220 趣味だけど実益兼ねているでしょ、アレは。 boost、Loki あたりはウチの会社じゃ普通に使ってるし。 222 名前：デフォルトの名無しさん mailto:sage [04/01/30 09:43] ベンチャーかな？ あんなの使ったら強制デスマーチですが何か？ 223 名前：デフォルトの名無しさん mailto:sage [04/01/30 10:09] 一応、大手って言われてます。 224 名前：デフォルトの名無しさん mailto:sage [04/01/30 16:06] Lokiなんか使うなとかは低レベルなやつが言ってるだけだろ。 会社じゃ低レベルな奴が足引っ張るみたいだな。 勘弁してほしい。 225 名前：デフォルトの名無しさん mailto:sage [04/01/30 16:29] >>224 > 会社じゃ低レベルな奴が足引っ張るみたいだな。 むしろ自分が使いたい言語の利点をきちんと説得できないのを恥じるべし 226 名前：デフォルトの名無しさん mailto:sage [04/01/30 16:44] >>222 それはいくらなんでもスキル低すぎだろ。 227 名前：デフォルトの名無しさん mailto:sage [04/01/30 19:51] >>225 いや俺会社員じゃないし。 話し聞いてると会社がそういうとこらしいのが嫌だなってこと。 228 名前：デフォルトの名無しさん mailto:sage [04/01/30 19:53] C++の話題はスレ違いです 229 名前：デフォルトの名無しさん mailto:sage [04/01/31 00:41] プロトタイプベース言語で開発するときは、分析モデルの中にクラスは登場するの? 実装モデルには当然クラスは出てこないんだろうけど 基本的にオブジェクトの発見がメインで、ドメインモデルでもクラスは見つけないのかな。 230 名前：デフォルトの名無しさん mailto:sage [04/01/31 00:43] プロトタイプベース言語で大規模プログラミングの例はありますか？ 231 名前：デフォルトの名無しさん mailto:sage [04/01/31 01:43] すれ違い覚悟で書くけど、 www.radiumsoftware.com/0312.html#031250 こういうのどうよ？ クラスの意味論？とかの観点を語れそうじゃね？ 232 名前：デフォルトの名無しさん mailto:sage [04/01/31 04:48] 訂正。後半のXenの事ね。 www.radiumsoftware.com/0312.html#031205 233 名前：デフォルトの名無しさん mailto:sage [04/01/31 20:22] プロトタイプベースのオブジェクト指向も、ある程度妥協してるよな。 prototypeなんてのを持ち込むくらいなら、素直にclassを認めた方がいいかなと 思ったり。 234 名前：デフォルトの名無しさん mailto:sage [04/01/31 20:38] それをクラスと呼んだ瞬間に、色々余計な概念が持ち込まれるのが嫌だったんでしょう。 クラスなんて本質的に必要なものじゃないし。 Ruby みたいに、クラスのインスタンスだけど後からあれこれ出来ますってのが、厨避け には良かったのかもしれない。 235 名前：デフォルトの名無しさん mailto:sage [04/01/31 20:49] >>233 プロトタイプはクラスとしても使える、という話じゃなくて？ 236 名前：デフォルトの名無しさん mailto:sage [04/01/31 21:37] いや、本来は継承元のメンバも全て自分が持ってるべきでしょ。 それをメモリ効率とかの観点から、prototypeを導入したわけだ。 それなら雛型としてのclassを認めた方が、むしろシンプルかなと思った。 237 名前：デフォルトの名無しさん mailto:sage [04/01/31 21:50] >>236 1,2 行目と 3 行目の繋がりが良く分からないな。「classを認める」というのは具体的に何を イメージされてるのですか。 238 名前：デフォルトの名無しさん mailto:sage [04/01/31 22:18] >>237 プロトタイプベースでも多くの場合、クラスとインスタンスの関係に近い オブジェクトをいろいろ用意して使うことになるよね。 それは、暗黙のうちにクラス的なオブジェクトとインスタンス的なオブジェクトを 使い分けてるってことで、なら割り切って、他にも利点のあるクラスベースの方が いいんじゃないかなぁと思った。 なんというか、プロトタイプは中途半端な気がする。やるならプロトタイプも なくしてしまえ! と。(w あー思いつきで適当に書きすぎた。 239 名前：デフォルトの名無しさん mailto:sage [04/02/01 00:17] class なんて特別なものをなくして、 simple にしたんだと思うけどなぁ… class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。 ところで prototype をなくす利点ってどのへん？ 派生先が派生元の変更に影響されなくなることくらいかな… 240 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:09] "特別扱いな部分が少ない言語 == シンプル && 優れている" っていう意識があったけど、 よく使いそうな機能は言語のコアに最初から組み込んでおくべきなんだって考えの人も 居るみたいね。>>232 のリンク先の論文とか。 241 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:14] そういう見方もあるけど、 プログラム=データ構造+アルゴリズムという観点で見ると、 なにか重要な示唆が含まれているような気もする。 242 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:34] >>238 >なら割り切って、他にも利点のあるクラスベース ここはトレードオフなんだよね。割り切って切り捨てられてしまったものが 結構便利だったりする。対象領域によってはクラス化しない方がシンプルな 場合も多いだろうし。 243 名前：デフォルトの名無しさん mailto:sage [04/02/01 02:59] >>239 > class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。 そんなのclassの実装次第でしょ。 244 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:22] >>243 それならそれを prototype と呼んでも良いわけだ。 よし、この FOO 言語のクラスは従来のクラスにあった制限を一切取っ払った実装にしよう。 ついでに名前も変えて prototype と呼ぼう。これで BAR 言語で出来なかったこんな事や あんな事も出来るようになるぞ。 245 名前：デフォルトの名無しさん [04/02/01 03:26] 型＝インスタンス ということ自体は全然構わないんだが、 グローバルにしたくないものをグローバルにする必要があったり メソッドの追加が煩雑だったりするのがかなわん 実用上大問題だと思うんだがどうよ？ 246 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:35] >>244 > ついでに名前も変えて prototype と呼ぼう。 そのFOO言語のclassがclassというよりむしろprototypeであることを ちゃんと理由を付けて説明できるのならね。 247 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:36] >>245 > 型＝インスタンス > ということ自体は全然構わないんだが、 誰がそんな事を言っているのですか？ このスレでは該当する者はいないようですが・・・ 248 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:47] >>246 実装次第でどうとでもなるなら、名前付けにも意味は無いですよねって事なんだけど。 249 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:55] >>248 とりあえず>>94読め。 250 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:58] >>249 それを読むべきなのは >>243 だろうね。クラスの制約の話をしていて、実装次第と いう答えはどうかと。 251 名前：デフォルトの名無しさん mailto:sage [04/02/01 04:11] >>250 おいおい、>>94に書いてあるのは、インスタンス生成機能をどこに配置するかという問題で、 それはクラスへの制約ではなくインスタンスへの制約なのだが。 クラスが一般のインスタンスと同様の機能を持つクラスベースOOPLだって存在するし、 そのOOPLでのクラスはプロトタイプではなく、あくまでクラスだ。 よってクラスへの制約は実装次第ということで間違ってはいない。 252 名前：デフォルトの名無しさん mailto:sage [04/02/01 04:25] >>251 クラスへの制約なんて話は今まで出てきてないけど、インスタンス生成に関する制約 って事かな。 だいたい、>>94 はインスタンス生成機能だけじゃなく、オブジェクトの分類にも 触れていると思うけど。その上で、モデリングの違いで使い分ければ良いとも読める。 253 名前：デフォルトの名無しさん mailto:sage [04/02/01 05:01] >インスタンス生成機能をどこに配置するかという問題で、 >それはクラスへの制約ではなくインスタンスへの制約なのだが。 ｽﾏｿ。ちゃんと読んでなかった。で、クラスへの制約って何? 254 名前：デフォルトの名無しさん mailto:sage [04/02/01 06:45] >>253 それは>>239に聞かないとわからん罠 255 名前：デフォルトの名無しさん mailto:sage [04/02/01 07:13] >>239 にはクラスへの制約なんて言葉は書いてない。>>251 の空想の中にしかない 概念なんだろうね。自分で参照したレスもちゃんと読んでないみたいだし。 でももう良いよ、終わりにしよう。説明するのも疲れた。 256 名前：94=249 mailto:sage [04/02/01 07:24] >>239より引用 > class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。 これがクラスへの制約でなくて何だと言うのだろうか・・・ 257 名前：デフォルトの名無しさん mailto:sage [04/02/01 08:00] なんか頭の痛くなる会話してるな >>255 >でももう良いよ、終わりにしよう。説明するのも疲れた。 説明がちゃんとできてないし、話もお互い通じてないな おまえら、ろくな定義もされてないあやふやな概念を 一方通行にただ垂れ流してるだけだ それで余計に疲れるんだろ 258 名前：デフォルトの名無しさん mailto:sage [04/02/01 10:29] で、分析モデルにクラスは出るのか出ないのか? 259 名前：1 mailto:sage [04/02/01 11:18] >>132 SeRuby はRubyでSelfライクを実現，ですが こちらはJavaScriptライク mput.dip.jp/?date=20030912 特異メソッド/クラス定義 凄い便利だよな．楽しいよな Rubyが完全にプロトタイプベースだったら… 260 名前：239 mailto:sage [04/02/01 15:41] え〜と、説明不足だったかな、ごめん。 class にしかできないことっていうのは、 instance とか subclass の生成あたり。 あとは処理系の柔軟性のなさに応じて、 method や property の追加・削除とか、superclass 変更とか。 class にはできないことのほうは、確かに柔軟な言語にはないかも。 普通の object として複製したり、書き換えたり渡したりってあたりを想定してたけど。 充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。 subclass 作ったり method 書き換えたりはしても、 class じゃない instance は作らないっていう。 で、これを簡潔にしたのが prototype-based OOP だと思う。 もう class なんて概念もいらなくなって、世界には object だけあればいい、っていう。 261 名前：デフォルトの名無しさん mailto:sage [04/02/01 16:46] >>260 > 充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。 整数とかはどうする？ 整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、 クラスとインスタンスの区別があったほうがずっとシンプルにならない？ クラスの有り無しは目的ではなくて手段にすぎないんだから、 「クラスを無くすには」「クラスを導入するには」ってのは 処理系実装以外のシチュエーションではナンセンスだと思う。 262 名前：238 mailto:sage [04/02/01 18:41] スレ伸びてるなぁ．びっくり． >>239 classとobjectを区別しないprototypeでも，実際に使うと自然に classとinstance的なものを考えるようになる． だから，classとinstanceは本質的に違うものであって，それを prototype-basedな言語は無理矢理まとめてしまった…とも考えられる． > ところで prototype をなくす利点ってどのへん？ > 派生先が派生元の変更に影響されなくなることくらいかな… これは結構大きい．派生元の影響を受けるから，自然にclass, instanceの を区別する使い方をしてしまうんだと思う． シンプル，という観点から見れば，prototypeすらないのが一番素直． ある程度メモリ効率とかを気にして，classやprototypeが考案されたと． そんな中で，prototype-basedは，やっぱりちょっと中途半端な気がする． 263 名前：デフォルトの名無しさん mailto:sage [04/02/01 19:16] >>262 プロトタイプすらないってどういうのを想像しているの？ オブジェクトの拡張はどうやってやるんでしょうか… 264 名前：デフォルトの名無しさん mailto:sage [04/02/01 20:32] 丸ごとコピーして変更じゃねーの？ 265 名前：デフォルトの名無しさん mailto:sage [04/02/01 20:39] >>261 > 整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、 > クラスとインスタンスの区別があったほうがずっとシンプルにならない？ あんまり差が思いつかない…どんなとこが違いそう？ >>262 > だから，classとinstanceは本質的に違うものであって，それを > prototype-basedな言語は無理矢理まとめてしまった…とも考えられる． 役割分担するにしても、厳格に分けないほうがやりやすいと思う。 それぞれの object を class とか instance って呼んでもいいけど、 いつでも役割交代させたり、一人二役させたりできる…っていう。 > シンプル，という観点から見れば，prototypeすらないのが一番素直． > ある程度メモリ効率とかを気にして，classやprototypeが考案されたと． 効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。 使う library 切り替えるときとか、関係する object 全部書き換えるのは大変だし。 それに、全部複製して持たせちゃうような method も、簡単に書けるよね。 どっちを default にするかの違いでしかないと思う。 両方用意するほうが親切だろうけど。 266 名前：263 mailto:sage [04/02/01 21:25] >>264 なるほど． >>265 >効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。 たまにじゃなくて，ほとんどの場合影響して欲しいと思うけど． 267 名前：デフォルトの名無しさん mailto:sage [04/02/01 21:38] そうかなぁ．継承関係はあっても，モノとしては全然関係ないobjectどうしが 影響し合うするのは良くないと思うけどなぁ． 268 名前：デフォルトの名無しさん mailto:sage [04/02/01 21:45] >>267 その、「良くないと思う」レベルが classベースと、 prototypeベースと、 なんも無しと、 で違うだけだよ。 269 名前：デフォルトの名無しさん mailto:sage [04/02/01 22:02] >>268 影響し合うのはprototype-basedだけじゃない? 270 名前：263 mailto:sage [04/02/01 23:20] >>269 クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑 271 名前：デフォルトの名無しさん mailto:sage [04/02/02 09:20] >>270 > クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑 そういう言語もアリだと思うけど。 instance creationした瞬間のclassがそのobjectのclassってことでしょ？ 272 名前：デフォルトの名無しさん mailto:sage [04/02/02 17:59] 多くのクラスベースな言語では，実行時にクラス変更なんて出来ないし， 出来たとしても，>>271のようになるのが自然だと思う． 273 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:33] >>272 > 出来たとしても，>>271のようになるのが自然だと思う． そんなこたーない。普通はクラスを変更したらインスタンスも変更される。 274 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:47] 普通はって、普通は実行時にクラスを変えられないような。 275 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:52] >>274 普通はって、「出来たとしても」という条件を満たした上での「普通は」でしょ。 文脈からいって。

---

---

[ 続きを読む ] / [ 携帯版 ]

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