{_proto: プロトタイプベース・オブジェクト指向};

1 名前：デフォルトの名無しさん [05/03/05 00:08:47 ] 実装談義も哲学論議も。 プロトタイプベース・オブジェクト指向とは　sumim.no-ip.com:8080/wiki/493 Google Directory Prototype-based　directory.google.com/Top/Computers/Programming/Languages/Object-Oriented/Prototype-based/ Self　research.sun.com/research/self/ Io　www.iolanguage.com/ ほか　>>2-10あたり 前スレ 　プロトタイプベース・オブジェクト指向 　pc5.2ch.net/test/read.cgi/tech/1070886635/ 2 名前：デフォルトの名無しさん [05/03/05 00:10:44 ] Cecil www.cs.washington.edu/research/projects/cecil/www/index.html www.kmonos.net/alang/etc/cecil.php Cel www.redwoodsoft.com/cel/ soopy soopy.sourceforge.jp/tutorial/soopyindex.html Water www.waterlanguage.org/ OScheme koala.ilog.fr/abaird/oscheme/oscheme.html Agora prog.vub.ac.be/research/agora/ Brain brain.sourceforge.net/ Obliq www.luca.demon.co.uk/Obliq/Obliq.html ECMAScript www.ecma-international.org/publications/standards/Ecma-262.htm NewtonScript wsmith.best.vwh.net/works.html www.cc.gatech.edu/~schoedl/projects/NewtonScript/ 3 名前：デフォルトの名無しさん [05/03/05 00:16:42 ] Io 文書Io Documentation f21.aaa.livedoor.jp/~kizz/prog/io/Docs_ja.html プログラミング言語 Io のはなし shinh.skr.jp/io/ 4 名前：デフォルトの名無しさん [05/03/05 00:22:04 ] SELF: The Power of Simplicity (和訳) www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html ＃原文はいずこ。。。？ 5 名前：デフォルトの名無しさん [05/03/05 00:36:48 ] NewtonScript www.k-inet.com/~brown/ftp/newton/Documents/NewtonScript.pdf www.kallisys.com/newton/einstein/ (Projet Einstein) 6 名前：デフォルトの名無しさん [05/03/05 01:04:04 ] SELF and the Origins of NewtonScript This is an introduction to the paper "Self: the power of simplicity", by Ungar and Smith. wsmith.best.vwh.net/Self-intro.html 7 名前：デフォルトの名無しさん mailto:sage [05/03/05 02:09:18 ] ruby並に普及すればいいね。まあ無理だろうけど。 8 名前：デフォルトの名無しさん mailto:sage [05/03/05 04:14:47 ] Luaは違うのか 9 名前：デフォルトの名無しさん [05/03/05 13:15:57 ] >>7 Rubyも特異メソッドに注目すればプロトタイプベースだよ。 ruby.mirror.easynet.be/ja/uguide/uguide16.html mput.dip.jp/?date=20030912 10 名前：デフォルトの名無しさん mailto:sage [05/03/05 16:37:19 ] うーん、だからそういうあんま共通点のない言語の集めてどうすんだよ。 プロトタイプならでわの話題があるわけでもなし。 ここでいままでされてきた話って、そういう風にも組めますね、だから何？ で終わりじゃないか。 プロトタイプベースにしたらプロジェクトに成功したとか、金持ちになったとか、 こんなメリットがあった、みたいな話を聞きたいな。 11 名前：デフォルトの名無しさん mailto:sage [05/03/05 16:39:37 ] うーん、だからそういうあんま共通点のない言語の集めてどうす んだよ。 プロトタイプならでわの話題があるわけでもなし。 ここでいままでされてきた話って、そういう風にも組めますね、だから何？ で終わりじゃないか。 プロトタイプベースにしたらプロジェクトに成功し たとか、金持ちになったとか、 こんなメリットがあったよ、みたいな話を聞きたいな。 12 名前：デフォルトの名無しさん [05/03/05 17:02:07 ] ＞あんま共通点のない言語の集めてどうすんだよ。 ＞プロトタイプならでわの話題があるわけでもなし。 だったら前スレは1000まで全うせんかっただろう。 まあ、POOのメリットを探るってのは欲しいな。 金持ちになれるかどうかは置いといてｗ 13 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:08:14 ] プロトタイプベース・オブジェクト指向って JavaScriptのことだろ。 すでに十分普及している。 14 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:10:21 ] > クラスでの定義の具体例（インスタンス）としてオブジェクトを > 生み出すのではなく、既存のオブジェクトの複製（クローン）、 > あるいは、それへの参照を持つことですべてを委譲する > オブジェクト（チャイルド）を生み出す手法で あーだめだ。今チャイルドと聞くと舞HiME思い出してしまう。 終わってから忘れるまであと半年ぐらいまってくれ。 15 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:10:46 ] POOてなんだよ。 馬鹿にしてるのッ！ 16 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:11:11 ] ﾌﾟｰ 17 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:13:16 ] >>16 プルートのことかーーー！ 18 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:13:35 ] ぷーはメリットよりデメリットの方が多そうだが 19 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:17:55 ] >>18 タブーを犯すと刈られるしな。 20 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:19:24 ] まあ、実質JavaScriptスレなわけだが。 21 名前：デフォルトの名無しさん [05/03/05 17:20:49 ] jp.rubyist.net/magazine/?0002-WCNewsPaper#l7 POOのメリットを活用しているRubyは、オライリーも出るほど普及してる。 どうせTraitsがなきゃやってられないんだから、 原理主義に陥らずメリットをうまく活かすのが吉かと。 22 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:23:41 ] オライリーも、それほどネタに困っているということだな。 23 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:26:48 ] 可読性とかについて語りたい。 個人的にはパスタをおいしく作る方法にしか見えない。 24 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:26:58 ] >>20 巣に帰れ 25 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:31:13 ] >>23 POOがなぜ可読性を下げると？ まあ、メソッドの定義がどれかってのを追うのはあれかな。 26 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:34:42 ] とりあえずPOOがどんなものか 語れ。 27 名前：デフォルトの名無しさん mailto:sage [05/03/05 17:39:11 ] >>25 23じゃないが、つまり、処理を追わないとオブジェクトが どんな機能を持つかわからないという事じゃないかな。 これはドキュメントを書くときにも困る。 静的型ならデータ型と、メソッドについて書いていけばいいが、 プーだと処理についても言及しなければならない。 28 名前：デフォルトの名無しさん mailto:sage [05/03/06 09:59:13 ] 処理を追わないとわからないというのは、使い所を誤ってないかな? Ruby等でもクラス/インスタンス特異を 無闇に 使ってると可読性が落ちるのと一緒。 29 名前：デフォルトの名無しさん mailto:sage [05/03/06 12:32:13 ] >>28 得意メソッドの正しい使い方を教えてください。 標準ライブラリのstringクラス拡張する奴とかがそれ？ 30 名前：デフォルトの名無しさん mailto:sage [05/03/08 00:21:29 ] blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/25772 こいつが猛烈に欲しいのですが…… 31 名前：デフォルトの名無しさん [05/03/11 03:26:08 ] >処理を追わないとわからないというのは、使い所を誤ってないかな? クラスとプロトタイプなオブジェクトと、両方が使えるんなら「使い所を誤ってないかな?」 という反論が有効だけど、そもそもクラスがない言語じゃどうしようもないよねえ。 なんかこう、クラスなんかなくてもいいぜ! 的なパラダイムシフトを求めてたんだが。 無理な話? 32 名前：デフォルトの名無しさん mailto:sage [05/03/11 21:31:01 ] >>31 関数型言語いじってみると結構パラダイムシフトするかもよ つーか（呼び方はともかくとして）プロトタイプベースだからクラスはないってことはないぞ。 33 名前：デフォルトの名無しさん mailto:sage [05/03/11 22:39:50 ] >>32 インスタンスの初期のメソッドのセットを定義するもの。 とか地味な存在になる感じですか？ 34 名前：デフォルトの名無しさん mailto:sage [05/03/12 18:17:52 ] この場合の、プロトタイプで用いるクラスってのは、 オブジェクトをハッシュデータ構造と考えて、 コンストラクタ ... 自分自身のクローン/コピーを返すメソッド 継承 ... データのマージ 程度で十分じゃないかな。フルセットの"クラス"は実装されてない言語もあるが、 クラスに相当するオブジェクトを作れば、プロトタイプでも従来どおりの記述が出来る。 35 名前：デフォルトの名無しさん mailto:sage [05/03/13 12:23:25 ] ハッシュって、テーブルでリソース食いまくりな気がするんだけど、 そういうのは無視？ 36 名前：デフォルトの名無しさん mailto:sage [05/03/13 17:30:09 ] >>35 関係ない 37 名前：デフォルトの名無しさん mailto:sage [05/03/14 00:40:00 ] >>36 何が？ 38 名前：デフォルトの名無しさん mailto:sage [05/03/14 01:17:17 ] ハッシュル！ハッシュル！ 39 名前：デフォルトの名無しさん [2005/04/19(火) 11:34:08 ] protoとparentの違いがやっと分った。 protoは意味上の親を表わし、 parentは構造上の親を表わすわけね。 しかしparentはGUIのイベント伝播以外に使いどころが あるのだろうか？ 40 名前：デフォルトの名無しさん mailto:sage [2005/04/19(火) 23:13:24 ] こんな中途半端な概念の物やるよりはhaskellとか関数型言語やった方がいいよ 41 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 12:42:29 ] HaskellでGUIはきついぞ？ 42 名前：デフォルトの名無しさん mailto:sage [2005/04/22(金) 20:23:56 ] そうか？ そうか・・・ 43 名前：ec mailto:sage [2005/04/23(土) 23:58:10 ] >>40 プロトタイプベースが中途半端だということですか？ クラスベースは中途半端ではないのですか？ どこが中途半端なのか教えてください。 44 名前：デフォルトの名無しさん mailto:sage [2005/04/24(日) 00:35:56 ] >>43 関数型言語と言ってるからクラスベース言語とは関係無いでしょう。 何かと言うとクラスベースを持ち出したがるのはこのスレの悪いクセだな。 >>40 プロトタイプベース言語もそれなりにとんがっている言語だと思うよ。 歴史的には Lisp/Scheme とかとクロスオーバーしている部分もあるし。 45 名前：デフォルトの名無しさん mailto:sage [2005/05/01(日) 19:36:12 ] >>44 プロトタイプベースOOのスレなんだから、比較対象としてクラスベースが 持ち出されるのはむしろ必然で、 こんなとこで脈絡なくHaskellを持ってくる方が、関数型言語ヲタクの 悪いクセだと思われ。 46 名前：デフォルトの名無しさん mailto:sage [2005/05/01(日) 20:32:46 ] 過剰反応だろ 47 名前：デフォルトの名無しさん mailto:sage [2005/05/03(火) 01:34:02 ] 多分、動的な型の扱いはまだ研究途上だから、 それより素性のはっきりしたHaskellでもやっとけ、 と言いたいんじゃないの？ 48 名前：デフォルトの名無しさん mailto:sage [2005/05/03(火) 03:25:05 ] 関数型でも型付きな言語が出てきたのは後からだべ 49 名前：デフォルトの名無しさん mailto:sage [2005/05/05(木) 04:06:21 ] ぱす。 50 名前：デフォルトの名無しさん [2005/05/20(金) 09:13:02 ] 309 名前： デフォルトの名無しさん 投稿日： 2005/05/19(木) 21:44:36 けれどクラスという概念をなくしてしまってもいい オブジェクトの構造・仕組みという抽象的なもので コード上は現れないようにしても問題ないだろうよ 311 名前： デフォルトの名無しさん [sage] 投稿日： 2005/05/20(金) 06:01:04 >>309 そういう道を進んでいる言語もある。 プロトタイプベースと呼ばれているようだが。 51 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 23:21:19 ] さて、プロトタイプるとするか ぷ ろ と たいぷ 52 名前：デフォルトの名無しさん mailto:sage [2005/07/25(月) 23:10:47 ] nanika 53 名前：デフォルトの名無しさん [2005/09/06(火) 18:11:34 ] ただいまのぷー儲数：０ ﾌﾟｰﾌﾟﾌﾟﾌﾟ 54 名前：デフォルトの名無しさん mailto:sage [2005/09/07(水) 02:09:57 ] オンザフライでメソッドを追加出来るのは今でも魅力的だと思ってる 55 名前：デフォルトの名無しさん [2005/09/10(土) 02:57:54 ] 結局は、オブジェクトの定義が動的か静的かって事じゃないの？ クラス継承もインスタンス化も、プロトタイプからの生成も、is-a関係と考えれば、 クラス定義が動的（タイミングが実行時という意味でなく、組み立て可能という意味） に出来れば、クラスのありなしって、関係ないんじゃね？ CoR云々て、そんなのを中心としたコーディングなんて有り得ないっしょ？ CoR Orientedなんて方法論が確立され無い限り（されるとは思えんが）。 56 名前：デフォルトの名無しさん mailto:sage [2005/09/10(土) 08:25:25 ] あらゆるオブジェクトがクラスであるようなクラスベースなら、プロトタイプベースと同じだね。 そうじゃなくて、毎回クラスとインスタンスを別に作らなきゃいけないとかだと、ちょっと面倒かな。 # プロトタイプからの生成は、 is-a 関係じゃなくても使うよ。兄弟とか。 57 名前：デフォルトの名無しさん mailto:sage [2005/09/10(土) 09:32:21 ] ぷー儲じゃないけど いじくる必要のないところは効率よくやってほしいもんだ つまり効率優先派とは常に衝突するな 58 名前：デフォルトの名無しさん [2005/09/13(火) 20:58:58 ] d.hatena.ne.jp/m-hiyama/ プログラマのためのJavaScript (7)- ↑JavaScriptのオブジェクト周りが丁寧に解説されてます。 知らない人はぜひこの機会に読んでみては。 # トレイツベースと呼ぶのはどうでしょ？ 59 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 22:37:32 ] ここは馬鹿の巣窟だな 60 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 23:03:51 ] >>59 あなたがTraitsを知らないことだけはよく分かりました。 61 名前：デフォルトの名無しさん mailto:sage [2005/09/14(水) 20:54:25 ] トレイトとクラスの違いがわかんないな。大した違いはないはずだけど 62 名前：デフォルトの名無しさん mailto:sage [2005/09/14(水) 21:18:00 ] >>61 やろうとしていることは同じです。 共通項の括り出しですね。 で共通部分と特有部分の関係を静的に表現するか動的に表現するかという違いではないでしょうか。 静的な表現がクラス-インスタンスで、動的な表現がトレイツ+オブジェクト。 POOのトレイツは単なる役割なので構造的にはクラスベースよりシンプルですね。 クラスベースの場合、インスタンスとクラスの違いは呼び方だけではなくって中身が違いますからね。 63 名前：デフォルトの名無しさん mailto:sage [2005/09/15(木) 03:06:32 ] 特定の名前スロットを特殊な使い方(_PROTO_とか）するところだけがなじめないんだけど、そういう実装以外ないのかな？ 64 名前：デフォルトの名無しさん [2005/09/16(金) 21:17:49 ] >>63 JavaScriptのことかな。 プロトタイプのようなしくみがないと自動委譲(=トレイツ)ができないけど、 それでもない方が良いということですか？ それとも何か別の案があるんですかね。 65 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 21:20:35 ] POOなんてアフォなのやめて プロパティ指向にしたらどうだ 66 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 21:51:14 ] >>64 そういう意味じゃなくて特定の名前スロットが特定の意味を持たされている部分がなにか嫌らしい感じしません？ ＣＰＵで言うところの特定のレジスタだけが特別扱い的なマシン特性の泥臭さがでてると言うか。 名前に機能をbindするのではなく機構として特別な設定を施した実装（スミマセン語彙貧弱で意味不明かも）みたいなものは無いのかと。 Cで言ったらiはintでループ専用みたいな割り振りされているのがキモチワルイというか。（そんな事ないけど→ｃ） 67 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 21:52:57 ] >>64 ぱっと分かるだけでもSelf, Io, NewtonScriptがそうだよ。 ＞ 特定の名前スロットを特殊な使い方(_PROTO_とか） 68 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 22:22:53 ] _が頭についてんだからシステム予約なのはあたりまえだろヴォケ 69 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 22:28:51 ] 「頭に _ は予約」が常識かどうかは知らないけど >>66 C++ の this ポインタとかもそうかと。必要悪。 70 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 22:31:02 ] schemeみたいにletとかlambdaさえ意味が変わってほっしー☆のかてめえは 71 名前：66じゃないけど mailto:sage [2005/09/16(金) 22:49:03 ] >>70 特定のスロットやら変数やらを特別視するってのは、結構言語仕様上気持ち悪いもんだよ 使い勝手を優先するとそうなる場合も多いんだけど 72 名前：デフォルトの名無しさん [2005/09/16(金) 22:53:14 ] >>63 最新仕様では無事使用禁止だから大丈夫 73 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 23:04:28 ] schemeのアレはコンパイラ作るときに困る 74 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 00:56:01 ] >>67 SELFは任意のスロット名が使えるから違う。 75 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 20:35:16 ] >>73 アレって何？ 76 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 21:09:16 ] 予約語がないことだろ 77 名前：デフォルトの名無しさん mailto:sage [2005/09/19(月) 22:20:49 ] defineとかlambdaとかって予約語じゃないの？ 78 名前：デフォルトの名無しさん mailto:sage [2005/09/19(月) 23:27:50 ] lambda は (コンパイル時に他の識別詞と区別されるような) 予約語ではなくて、スペシャルフォームという define は普通にシステム定義関数で作れたような希ガス 79 名前：デフォルトの名無しさん [2005/09/23(金) 06:02:48 ] つまり(let ((define 〜))〜とか (lambda(lambda)〜 とかできるわけですか！ 80 名前：デフォルトの名無しさん mailto:sage [2005/09/23(金) 06:51:23 ] さらに (define lambda list) (define if append) (define-syntax define (syntax-rules () ((_ x) 'x))) (if (lambda 1 2 3) (define 4)) --> (1 2 3 . 4) もオケ〜イ 81 名前：デフォルトの名無しさん mailto:sage [2005/09/23(金) 06:58:14 ] うあｗ、それ困るわｗ 82 名前：デフォルトの名無しさん [2005/10/02(日) 03:45:23 ] なんで？ 人間が読むんじゃなくてコンパイラだろ？ そんなのCのプロプロセッサにスコープがついただけじゃん？ 83 名前：デフォルトの名無しさん mailto:sage [2005/10/02(日) 03:52:38 ] ↑真性の馬鹿 84 名前：デフォルトの名無しさん mailto:sage [2005/10/02(日) 08:00:19 ] よく分かんないけどクラスベース言語のthisとかsuperとかself とかも気持悪いってことか。ないと困ると思うけどな。 85 名前：デフォルトの名無しさん mailto:sage [2005/10/02(日) 08:16:07 ] 話を蒸し返す様だが、当然それらを自分で変更可能な言語もある 86 名前：デフォルトの名無しさん mailto:sage [2005/10/02(日) 15:23:49 ] >>81 今Schemeの処理系作ってるけどそんなに困らないぞ。 87 名前：デフォルトの名無しさん [2005/10/02(日) 16:08:44 ] >>83 真性のバカ。 実際この仕様でいろんな実装でコンパイルできてるのに、何を言ってんだろ。 88 名前：デフォルトの名無しさん mailto:sage [2005/10/02(日) 17:08:06 ] SELF とか SCHEME とかせいぜいがんばってくれ。 RUBY 並に普及するのは不可能だろうけどね (w 89 名前：デフォルトの名無しさん mailto:sage [2005/10/02(日) 18:01:02 ] >>88 ヒント：JavaScript (ECMAScript) つかscheme自体はOOじゃねぇし。アフォか。 90 名前：デフォルトの名無しさん mailto:sage [2005/10/03(月) 01:53:14 ] アフォはてめーだよ。マイナー言語厨が。マイナーな技術を選ぶ事が 目的になってんじゃねーのか。JavaScript が今後もプロトタイプベース 一本でいくと思ってるの？ つかプロトタイプベースの OO にあって Ruby にない利点があるのかよ (w Scheme はついでだ。ユーザビリティが低いから氏ね。 91 名前：デフォルトの名無しさん mailto:sage [2005/10/03(月) 01:55:15 ] おやまあ、、、 92 名前：デフォルトの名無しさん mailto:sage [2005/10/03(月) 01:55:29 ] Ruby が使いやすいのなら、それを使えば良いじゃない。 俺はマゾだから茨の道を行くよ。 93 名前：デフォルトの名無しさん mailto:sage [2005/10/03(月) 02:17:18 ] 整理すると、 * プロトタイプベースには Ruby と比較するとメリットはない * マゾには嬉しいらしい ということか。なんだつまらん。 94 名前：デフォルトの名無しさん mailto:sage [2005/10/03(月) 02:18:26 ] よくできました 95 名前：デフォルトの名無しさん mailto:sage [2005/10/03(月) 02:58:49 ] ええいいちいち反応するな 96 名前：デフォルトの名無しさん mailto:sage [2005/10/04(火) 08:18:47 ] RubyもJS2.0もなかなかブラウザに搭載されませんねー。 97 名前：デフォルトの名無しさん mailto:sage [2005/10/05(水) 01:53:12 ] そうだね 98 名前：デフォルトの名無しさん mailto:sage [2005/10/05(水) 02:23:54 ] self の良い書籍ってない？ 99 名前：デフォルトの名無しさん mailto:sage [2005/10/05(水) 06:19:32 ] 書籍自体無いんじゃないかな。リサーチプロジェクトだし。 100 名前：デフォルトの名無しさん mailto:sage [2005/10/06(木) 07:01:47 ] 終了

---

---

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

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