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