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

1 名前：デフォルトの名無しさん [03/12/08 21:30] オブジェクトを複製または継承によって生成を行う言語， プロトタイプベース・オブジェクト指向言語について語りましょうよ． 関連リンク >>2 152 名前：デフォルトの名無しさん mailto:sage [04/01/25 16:12] >>149 Refactoringは元々Smalltalkerの流儀から来ている。 Smalltalkはオブジェクトを生かしたまま(つまりプログラムの実行中に) クラス定義を変更したりメソッドを書き変えたりできるから、 まずは何かとりあえず動くオブジェクトを作ってみて、 動かしながら変数をいじったりメソッドを変更していく流儀が前提にあって、 その中から使用頻度が高く機械的にできる変更のパターンをまとめたのが Refactoring。 別の言い方をすれば、Refactoringは変更し難い言語で変更を容易にするものではなく 元々どうにでも変更しやすい言語で、変更の仕方を分類整理して名前をつけて、 初心者への教育とか、プログラマ間のコミュニケーションを改善するものだと思う。 だから、変更のし難さというのはクラスベースだからというわけではなく、 むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。 つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と 同一視したことによる縛り。 153 名前：デフォルトの名無しさん mailto:sage [04/01/25 16:31] >>152 > だから、変更のし難さというのはクラスベースだからというわけではなく、 > むしろ静的型の弊害であり、かつ、クラスをそのまま型として使うことの弊害だと思う。 > つまり、クラスの内部設計(インスタンス生成機構)をクラスの外部仕様(型)と > 同一視したことによる縛り。 うおー、目からウロコだー！ありがとうございます！ >>150-151 議論が噛み合っていない気がするなあ。もうちょっと冷静にやろうよ。 154 名前：1 mailto:sage [04/01/25 16:41] >>152 >その中から使用頻度が高く機械的にできる変更のパターンをまとめたのが >Refactoring。 はぁ？ リファクタリングはパターンじゃないんですけど… 使用頻度とか機械的だとかコミュニケーションとか関係ないんですが． リファクタリングとは，ソフトウェアの外部的振る舞いを保ったままで， 内部の構造を改善していく作業を指します． (リファクタリング プログラミングの体質改善テクニック) 155 名前：デフォルトの名無しさん mailto:sage [04/01/25 16:49] >>154 うーん、リファクタリングには定石はあるわけで、それを「パターン」と呼んでも リファクタリングの趣旨からは離れはしないと思いますよ。 実際、「この長いメソッドは別クラスとして独立させてね」という感じで パターンを意識したコミュニケーションも行われているし。 まあ、スレ違い気味ではあるが。 156 名前：デフォルトの名無しさん mailto:sage [04/01/25 16:49] パターンってデザインパターンだけを指す言葉ではないよ。本来はもっと意味が広い。 「アナリシスパターン」 や 「Smalltalk ベストプラクティス・パターン」 があるように。 名前を付けて体系化することで、暗黙知を形式知とすることと、 コミュニケーションするときの共通語彙として使えるようにすることが パターンの目的というか役割。 157 名前：1 mailto:sage [04/01/25 16:57] >>155 >>156 言いたいことはわかります． ただ用語の定義が正確ではないと思ったのでレスしました． 「使用頻度が高く機械的にできる変更のパターン」を リファクタリングと呼ぶのは間違いです． リファクタリング・パターンとでも言うべきでしょう． リファクタリングという作業自体には使用頻度が低いものもあるし， 機械的に行うことが難しいものもあるのです． 158 名前：デフォルトの名無しさん mailto:sage [04/01/25 16:58] >>150 ライブラリ利用時の保証ならクラスブラウザで良いし、実行時の保証ならリフレクションを 使う事になるんじゃないのって事なんだけど。 159 名前：デフォルトの名無しさん mailto:sage [04/01/25 17:19] んでもって、Happy Squeaking!! と SML の該当箇所。 ttp://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/S4-5-5_1.html ttp://www.sra.co.jp/smalltalk/SML/archives/1999-March/thread.html#3323 Smalltalk でインターフェイスを実装する話。操作の集合としてインターフェイスを 付けるのは良いけど、静的な型システムの代用とはならない。 160 名前：156 mailto:sage [04/01/25 17:25] >>157 スレ違いなのでこれで最後。 漏れは ｜使用頻度が高く機械的にできる を含めた定義には賛成しないよ。 161 名前：155 mailto:sage [04/01/25 17:40] >>160 スレ違いなんだけど、私も一つだけ。 私は基本的に「使用頻度が高く機械的にできる」を支持したいなあ。 ソフトウェアの改善という、それまで「一から書き直したほうが早い」と されてきた手のつけようのない難事業を、 ある程度機械的に処理できるようになったことが、リファクタリングの 第一のご利益だと思うから。 もちろん、リファクタリングの中には、それではすまない部分もあるけど。 162 名前：Java厨 mailto:sage [04/01/25 18:04] >>152,>>153 すまぬ。interfaceとclassで、型として何が違うというの？ 実装があるかないかの違いだけで、 interfaceは型そのものじゃないか？ Smalltalkがわからんのでリンク先読んでも肝心なところがわからん。 いってみれば、classはvoid型たれ、ということ？ じゃあ、classってなに？ 163 名前：デフォルトの名無しさん mailto:sage [04/01/25 18:56] >>159 んでもって、変数宣言時にインターフェイス(の集合)を指定すれば静的型付になる。 この場合の型はクラスとは独立しているからプロトタイプベースでも可能でしょ？ 164 名前：152 mailto:sage [04/01/25 19:15] 厳密に言えば、1氏の言う通り、Refactoringは仕様を変えずに実装を変更する 作業であって、パターンそのものではないです。 しかし、Refactoring作業のカタログ化はFowlerの"Refactoring"のPrefaceに | The heart of the book, the catalog of refactroings, stretches from | Chapter 5 through Chapter 12 とあるように、FowlerがRefactoringを普及させるにあたって念頭に置いてい ることと合致していると思います。 そして、>>149の文脈では 「あるRefactoring作業パターンのリストがあって、 そこから現状の実装に適切な作業パターンを選んで実行することで 漸近的により良い実装に近付けていく。」 という意味合いが強いと思い、あえてカタログ化としての面を前面に出し >>152のように書きました。 また、「機械的に」や「使用頻度が高い」についても同様で、 Refactoringという作業そのものの定義とは関係ありませんし、 実際に当てはまらないパターンもあります。 しかし、FowlerがRefactoringをカタログ化するにあたって、それぞれ 非常に重要な基準の一つであったのではないかと、 彼の"Refactoring"に掲載されたカタログから推測しました。 165 名前：デフォルトの名無しさん mailto:sage [04/01/25 19:36] >>162 あなたの質問は、いつも私の知りたいポイントを突いているなあ。 ということで、どうかどなたかお教えください。 今までの議論を自分なりに理解すると、 ・型、インターフェース…そのオブジェクトにどのような操作が可能か 　定義するもの。 ・クラス…そのオブジェクトがどのような継承関係で成り立っているか、 　ライブラリの中でどのような位置にあるかを示すもの。 なのでしょうか？ 私もJava厨なので、この二つが別物というのは驚きだし、いまいち 実感が湧かない。 166 名前：1 mailto:sage [04/01/25 19:39] >>152 いや，まぁ… なんというか 余計な事に突っこんですまんでした． Fowlerの本読むとリファクタリングのカタログ的な面が強調され過ぎてて ちょっと堅苦しいなぁと思ってたんです． その後Kent BeckのTDD本読んだら「機械的に」や「使用頻度が高い」とか はあまり関係なくて，リファクタリングという作業，リズムが重要だというか… 167 名前：Java厨 mailto:sage [04/01/25 19:50] >>165 >>152をもう一回読んで小便したら気がついたのだが、 classは動的に出来ること(メソッド)がどんどん変わってよい(Javaではできない)、 ということではないかと。 そのときそのときで、なにかのinterfaceの条件にあっていればよい、と。 しかし、それはいびつだなぁ。Aさんが小学生だったのが中学生になり、かつバスケの選手になる、 というのはあるが、全人類が小学生や中学生バスケ選手になることはないと思う。 うーん、やっぱりクラスって何？ 168 名前：デフォルトの名無しさん mailto:sage [04/01/25 20:07] 今、このスレは自分的には、2chでいちばんの良スレだ。 もちろんアカデミシャンからは稚拙な議論なのだろうけれど、 自分がずっと興味があって、しかし仕事と直接の関わりがなくて手を出せなかった 分野を、何とか自分に理解できるレベルで話してもらえるというのは最高です。 皆さんどうもありがとう。 169 名前：152 mailto:sage [04/01/25 20:15] >>166 > その後Kent BeckのTDD本読んだら「機械的に」や「使用頻度が高い」とか > はあまり関係なくて，リファクタリングという作業，リズムが重要だというか… そうですね。Kent BeckはXPからもわかるように、開発プロジェクト全体の 手法のほうに着目してますから。 ところでプロトタイプベースでもリファクタリングみたいな作業は重要だと思いますが、 ↓こんなのがありますね。 selfguru.sourceforge.net/ 個人的にはC++やJavaのような「堅い」言語よりも、プロトタイプベース言語のほうが Refactoringのカタログを充実させる要請が強いと思うのですが、どうでしょう？ オブジェクトをクラスではなくインスタンス単位でまとめていくために必要になる 「カン所」にうまく名前を付けて、多くのプログラマからそれらを集積して整理する ことで、プログラマの能力をよりよく発揮させられると思うのですが。 170 名前：デフォルトの名無しさん mailto:sage [04/01/25 20:19] クラスとはオブジェクトを作る"元"で、オブジェクトの構造(実装)やメソッドを定義しておいて、 その類(クラス)のオブジェクトが共通に使うものって事? で、C++やJavaはクラスを型としても使ってしまっているから混乱するって事? Smalltalkがクラスを型として使っていないってのは、オブジェクトが何のクラスに属するかは きっちり決まっていて、クラスからオブジェクトを生成するけど、 オブジェクトをポイントする変数そのものには型が無いって事? Java のインタフェースも思いっきりクラスの気がするんだけど。実装は持たないし オブジェクトを作る元にもならないけど、継承もできるし、オブジェクトの分類を示すものには 違いないでしょう? それでもやっぱり抽象データ型の変形に過ぎないのかな? 171 名前：152 [04/01/25 20:32] >>167 > というのはあるが、全人類が小学生や中学生バスケ選手になることはないと思う。 OOの話で例え話はあまり好きじゃないのですが、バスケ選手の話で言えば、 playerという変数の型として、PlayerだのNBAProといったクラスはどうでもいい話で、 むしろmoveableとかthrowableといったインターフェースが重要じゃない？ player.run_to(direction, distance, speed)とかplayer.throw_at(direction, speed)とかが ちゃんと実行できることが大事なんじゃない？ Playerクラスをplayerの型としてしまうと、車椅子バスケとかに対応しようとした時に PlayerクラスにFoot leftfoot, rightfoot;なんて変数があったら困ることになるかもよ？ 本当はmoveableでthrowableならFootがあろうがなかろうが関係ないんじゃない？ という話です。 172 名前：1 mailto:sage [04/01/25 20:36] >>168 なんか最近妙に賑わってるのがなんか怖いw このスレ立てたのが，プロトタイプベースに関する日本語の資料がほとんど見つからなかった という理由なんだけど，興味ある人/知ってる人はけっこういるみたいね． 俺もSelfとか使ってみたいんだけど… 初心者が簡単に手をつけられる状況じゃないよなぁ． 173 名前：デフォルトの名無しさん [04/01/25 21:10] >>167ではないけれど >>171 ならinterfaceのあるJavaは問題ないということですか？ 174 名前：Java厨 mailto:sage [04/01/25 21:29] >>171 interfaceの適切な粒度とそれ中心で考えるというのは理解するし、普段から心がけている。 話はそれではなく、クラスの定義がどんどん変わると、 世界に散らばったインスタンス達も同様に変わってしまうわけで、 それは普通は変ではないかと。 個々のインスタンスが変身していくのはわかるけど、と。 こう考えると、クラスってなに？と。 クラスベースでクラスにこういうことやるのはおかしくない？と 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 はインスタンス生成機能だけじゃなく、オブジェクトの分類にも 触れていると思うけど。その上で、モデリングの違いで使い分ければ良いとも読める。

---

---

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

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