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

1 名前：デフォルトの名無しさん [03/12/08 21:30] オブジェクトを複製または継承によって生成を行う言語， プロトタイプベース・オブジェクト指向言語について語りましょうよ． 関連リンク >>2 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 > プロトタイプベースと呼んでいいものかどうかわかりませんが、 > 実装を考えれば自然な発想で、プロトタイプベースに通じるものがあると思います。 モジュールはコピれないところがちょっと厳しいけど、 オブジェクト的なエンティティの直接記述という意味では 確かにプロトタイプベース的だよな。

---

---

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

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