結局OOpが役に立たないのはなぜ?
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/04/14(水) 01:14:080153デフォルトの名無しさん
2010/04/21(水) 22:46:41きれいに整理したい。
とりあえず、型の定義から、インターフェースを整える仕事を排除したい。
それで第一歩かな。
どうせ、整いやしないわけで。別でやったほうがいい。
0154デフォルトの名無しさん
2010/04/21(水) 22:48:23ライブラリ使ったら「壮大」ってのは、それこそ、火打石と薪じゃねーか。
ライブラリぐらい普通に使うだろ、どう考えても。勘弁してくれ。
0155デフォルトの名無しさん
2010/04/21(水) 22:50:06> きれいに整理したい。
↓
> とりあえず、型の定義から、インターフェースを整える仕事を排除したい。
？？？
>>154
> ライブラリ間でインターフェースが整わない
0156デフォルトの名無しさん
2010/04/21(水) 22:54:13ポリモは呼び出し元の仕事。型の定義に含めるべきではない。
0157デフォルトの名無しさん
2010/04/21(水) 22:58:13よく分からんが、それは、君のところの開発体制がダメダメなだけじゃ？
0158デフォルトの名無しさん
2010/04/21(水) 23:02:18あとは偉い人、制御、処理、プロシージャ、関数が何とかする。
型が自分以外のことをするのは越権行為だ。物事をややこしくする。
インターフェースを整えたり、他のオブジェクトの内容を書き換えたりはしなくていい。
型はアトミックであればそれで良い。その安全さが型の価値だ。
>>156
おれはソフト屋じゃねーから知らん。
部長→関数
平社員→型
の比喩表現だ。
0159デフォルトの名無しさん
2010/04/21(水) 23:07:33> 型が自分以外のことをするのは越権行為だ。物事をややこしくする。
それが、抽象型ベースなオブジェクト指向の考え方なんじゃないの。
インタフェースを整えるのは、自分のすべきこと、すべきでないことを明確にするため。
> おれはソフト屋じゃねーから知らん。
ソフト書かないのにオブジェクト指向スレで暴れるとはまた奇特なお人だな。
0160デフォルトの名無しさん
2010/04/21(水) 23:13:25今でもC言語オンリーで立派な成果を出しているプロジェクトは確かにある。
一方で、いくら「○○であるべき」と言い募っても、オブジェクト指向的な考え方に基づいた
開発で成功しているプロジェクトも既にたくさんある。
前も紹介したけど、一度、オープンソース・プロジェクトのソースコードを読んでみるといい。
0161デフォルトの名無しさん
2010/04/21(水) 23:18:13自分のすべきことを明確にするために、インターフェイスを整える必要は無い。
整って無くても何でもいいからメソッドが有ればそれでいい。
無いメソッドは呼べない。有るメソッドは機能するとみなす。
インターフェースを整えるのは、呼び出し元のポリモを意識している。
そんなことはしてもらわなくて結構。おせっかいが過ぎる。
出来もしないおせっかい。後でアダになる。
0162デフォルトの名無しさん
2010/04/21(水) 23:28:19今更だが、「呼び出し元のポリモ」って何？ 意識するって具体的には？
0163デフォルトの名無しさん
2010/04/21(水) 23:30:57C++で言えば、共通の基底クラスを持つことだ。
0164デフォルトの名無しさん
2010/04/21(水) 23:35:44さっきのライブラリ間でインタフェース共通化とかいう話もそうだが、
共通って、どれくらいのクラス数を意識した話なんだ？
「継承で共通化で再利用で差分プログラミング！」って、最近はむしろあまり推奨されないだろ。
0165デフォルトの名無しさん
2010/04/21(水) 23:39:51あー頭痛くなってきた。
正しいこと書けば書くほどバカしか釣れなくなってくる。
もう出涸らしだな、このスレ。今日はこの辺が引き際か。
0166デフォルトの名無しさん
2010/04/21(水) 23:42:280167デフォルトの名無しさん
2010/04/22(木) 00:27:0813.反論できなくなると必ず勝利宣言
0168デフォルトの名無しさん
2010/04/22(木) 00:32:23勉強したいので、もう少し説明をお願いします
ある型は必要最小限の操作のみを持ち、それ以外は使う時に呼び出し側で変換関数を準備する、ということですか？
たとえばRubyでeachさえ実装すればEnumerableをMixinしてmap等が使えるようになる、というイメージはおっしゃっていることに近いですか？
0169デフォルトの名無しさん
2010/04/22(木) 01:24:29型が操作持つ必要性とかってあるのか?
clos みたく, ある特定の操作が, 型を知ってればええんちゃうの?
0170デフォルトの名無しさん
2010/04/22(木) 08:09:28彼は「オブジェクト＝データ型＝構造体」という図式を大前提に、
『オブジェクト指向プログラミングの各要素技術は関数と構造体のみで実現できる！』
という主張を繰り返しているだけなので、真面目に話を聞くだけ無駄だと思うよ。
そりゃ、実現自体はできるかもしれないけどな。
>>141でも書いた通り、「高凝集度・疎結合なシステム」という目的に貢献しない
要素技術の話をいくらしても、オブジェクト指向開発の議論とはあまり関係がない。
0171デフォルトの名無しさん
2010/04/22(木) 08:17:54カプセル化はどう実現するんだ？
0172デフォルトの名無しさん
2010/04/22(木) 17:17:57実行時に、全引数の実行時型に基づいてグローバルに関数検索することで
多態を実現するんだよな？
それは分かるしいいとして、型自体は静的型なのか動的型なのか、
どういう言語を想定してるのか、ちょっとよくわかんなかった
型が静的に決定されるケースだと、そもそも多態にはならんし
実行時検索は要らんよね？
動的型のようなものを考えているのか
継承・クラスベース＆参照型なのか
0173デフォルトの名無しさん
2010/04/23(金) 03:50:51便乗質問です。
「ポリモするのは呼び出し側の都合」の意味をもう少し教えてください。
同じメソッドや関数を呼び出しても、対象や引数の型によって異なる動作をするのがポリモだと思うのですが、
呼び出し側の都合で動作を変えられるべきだということですか？
0174デフォルトの名無しさん
2010/04/23(金) 08:34:46道具に机上で妄想や俺ルールで文句垂れるより実例示せ
0175デフォルトの名無しさん
2010/04/23(金) 13:02:58138じゃないが、オーバーロードはオブジェクト指向の多態性では無い。
オブジェクト指向の多態性は、呼び出し側は、どの機能が実行されるか意識する必要はない。
オブジェクト自身が、どの機能を実行するかを判断する。
オブジェクト指向基本は、書いて字のごとくオブジェクトを指向する、つまりオブジェクトを主体に考えるパラダイム・シフト。
138は、オーバーロードじゃなくアダプタ関数を勧めていたが（Adapterパターンで無いようだが？）
始めから、１つのメソッドに対して異なる機能があると分かっている場合の
オブジェクト指向的なコーディングするのなら、Strategyパターンで機能を「オブジェクト」として実装する。
0176デフォルトの名無しさん
2010/04/23(金) 21:30:27>実行時検索は要らんよね？
あるインスタンスの型が静的に決定されていたとしても、
参照やポインタの指すインスタンスの型は動的に判断されることが望まれる。
C++でやるなら、void *p の指す型を正しく判別できる必要があるね。
>「ポリモするのは呼び出し側の都合」の意味をもう少し教えてください。
ポリモは何のためにある？
呼び出し側のコードを一元化するためだろ？
>オーバーロードはオブジェクト指向の多態性では無い。
脱OOPの為に色々策を講じてるわけだから、俺からすりゃそりゃ本望だ。
>オブジェクト指向基本は、書いて字のごとくオブジェクトを指向する、
>つまりオブジェクトを主体に考えるパラダイム・シフト。
手続き型言語の主体はオブジェクトではなくて処理だと言ってるわけで。
それは、プログラムの機能が「処理でオブジェクト間の関係を定義する」ことで成り立ってるから。
オブジェクト間の関係の定義が、そのオブジェクト自体に含まれるのは都合が悪い。思考の妨げになる。
上手くいくのはアクセサぐらい。なぜならアクセサは自己完結だから。
0177デフォルトの名無しさん
2010/04/23(金) 21:48:140178デフォルトの名無しさん
2010/04/23(金) 21:49:24一般的な静的型言語ではありえない状況がごく頻繁に起こりそうだけど
それに関してはどうすんの
実行時エラー？
0179175
2010/04/24(土) 00:51:08>手続き型言語の主体はオブジェクトではなくて処理だと言ってるわけで。
>それは、プログラムの機能が「処理でオブジェクト間の関係を定義する」ことで成り立ってるから。
「処理でオブジェクト間の関係を定義する」は間違い、「メッセージでオブジェクト間の関係を定義する」が正しい。
なぜ、オブジェクト指向はメッセージと言う言葉を使うのか理解出来ない奴は、オブジェクト指向を理解していない。
上でも書いたが、オブジェクトが主体的に動くもので、そのオブジェクト間のメッセージは非手続き(4GL)な関係になる。
・処理（手続き）---相手から決まった順番で複数回の通信することにより、機能を実現する。
・メッセージ ---相手から１回の通信で、機能を完結する。（メッセージパッシング）
>オブジェクト間の関係の定義が、そのオブジェクト自体に含まれるのは都合が悪い。思考の妨げになる。
>上手くいくのはアクセサぐらい。なぜならアクセサは自己完結だから。
意味がよく分からんが、オブジェクト間の関係など意識する必要はない、逆に意識が必要なら
それは、オブジェクト間が手続きになっている証拠。
0180デフォルトの名無しさん
2010/04/24(土) 01:27:05> >オーバーロードはオブジェクト指向の多態性では無い。
>
> 脱OOPの為に色々策を講じてるわけだから、俺からすりゃそりゃ本望だ。
それで、君のオレオレオーバーロードは「高凝集度・疎結合」という目的の実現に対して
具体的にどういうメリットがあるの？
0181デフォルトの名無しさん
2010/04/24(土) 01:29:400182デフォルトの名無しさん
2010/04/24(土) 01:35:390183デフォルトの名無しさん
2010/04/24(土) 01:42:17最初は注目されてたけど。どっちも中途半端。
0184デフォルトの名無しさん
2010/04/24(土) 01:43:520185デフォルトの名無しさん
2010/04/24(土) 01:53:280186デフォルトの名無しさん
2010/04/24(土) 13:05:59オブジェクト指向にも何か理論があるのですか？
0187デフォルトの名無しさん
2010/04/24(土) 14:21:15理系は理論を学ぶ
文系出身者は思想ばかりで理論を伴わない故に説得力に欠ける
理系出身者は理論ばかりで思想を伴わない故に協調性に欠ける
0188デフォルトの名無しさん
2010/04/24(土) 14:51:12良いこと言う
あと、実地や経験を伴わない哲学は中二病に似たりとも言う
0189デフォルトの名無しさん
2010/04/24(土) 14:58:21協調性に欠けていても、出力が有用なら価値がある。
協調性があっても、出力が(ry
0190デフォルトの名無しさん
2010/04/24(土) 16:38:44回答いただきありがとうございます。
>>「ポリモするのは呼び出し側の都合」の意味をもう少し教えてください。
>ポリモは何のためにある？
>呼び出し側のコードを一元化するためだろ？
ポリモは同じ操作が適用できるものを統一的に扱うためにある
と考えていました。
確かに呼び出し側のコードが一元化されます。
そう考えると、呼び出し側でどの操作セットが必要かが変わるため、
型でインターフェースを整える必要はない（>>158）という意見も
理解できてきた気がします。
0191デフォルトの名無しさん
2010/04/24(土) 16:41:35通常は次のようにクラス定義でComparableインターフェイス
のようなものを実装すると思います。
interface Comparable {
boolean equals(Object o);
}
class MyClass implements Comparable {
boolean equals(Object o) {
//
}
}
しかし、呼び出し側で必要な操作セットはプログラムによって異なるため、
このようなインターフェイスをクラスの作成時に網羅して準備するのは不可能です。
ならばMyClassはimplementsのないシンプルなものにしておいた方が良いというのも理解できます。
その場合に、もしequalsを実装しているクラスの集合を「呼び出し側で」定義でき、
それを使ってポリモで呼び出せるならば、その方がシンプルで良さそうな気がします。
implements Comparable { MyClass, SomeClass, ... } // 構文は適当です
Comparable c[2];
c[0] = new MyClass;
c[1] = new SomeClass;
// この後、ポリモで使う
if (c[n].equals(something)) { // }
0192デフォルトの名無しさん
2010/04/24(土) 18:09:290193デフォルトの名無しさん
2010/04/24(土) 18:24:26> なぜ、オブジェクト指向はメッセージと言う言葉を使うのか理解出来ない奴は、オブジェクト指向を理解していない。
だから、そのオブジェクト指向とやらが嫌だと言ってるんだが。
手続き型言語だったら、素直に手続きで定義すりゃいいだろ。
> 上でも書いたが、オブジェクトが主体的に動くもので、そのオブジェクト間のメッセージは非手続き(4GL)な関係になる。
あー染まってるな。
オブジェクトが主体的に動く？きめぇ。
主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。
> ・処理（手続き）---相手から決まった順番で複数回の通信することにより、機能を実現する。
> ・メッセージ ---相手から１回の通信で、機能を完結する。（メッセージパッシング）
↑これどうする？かなりアホな発言に見えるのだが。
こういい直すことも出来る。
・関数の中身 --- 決まった順で処理を逐次実行することにより、機能を実現する。
・関数の呼び出し --- 一回の呼び出しで、その関数の機能は完結する。
ちょっとは考えてから発言すれば？
0194デフォルトの名無しさん
2010/04/24(土) 18:29:36> ・処理（手続き）---相手から決まった順番で複数回の通信することにより、機能を実現する。
> ・メッセージ ---相手から１回の通信で、機能を完結する。（メッセージパッシング）
が気に入ったからもっと弄ってやろうと思う。
手続きって何だ？
<完結した処理1>;
<完結した処理2>;
<完結した処理3>;
こういうことだよね。
この、一つ一つの<完結した処理#>をメッセージとリネームすることは勝手だけど、
<メッセージパッシング1>;
<メッセージパッシング2>;
<メッセージパッシング3>;
こうなるだけで、結局は同じことだよね。
0195デフォルトの名無しさん
2010/04/24(土) 18:31:03>主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。
その発想が非OOP脳なんだろうな。
0196デフォルトの名無しさん
2010/04/24(土) 20:03:00>だから、そのオブジェクト指向とやらが嫌だと言ってるんだが。
>手続き型言語だったら、素直に手続きで定義すりゃいいだろ。
だったら「関数」を使え、「オブジェクト間」とか使うなアホっほいぞ。
>あー染まってるな。
>オブジェクトが主体的に動く？きめぇ。
>主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。
管理するとか、本当にバカだな、管理すると言う事は主従関係だぞ。
>・関数の中身 --- 決まった順で処理を逐次実行することにより、機能を実現する。
>・関数の呼び出し --- 一回の呼び出しで、その関数の機能は完結する。
何を言っている？ バカか？ 「関数の中身」と「関数の呼び出し」って、大丈夫か？
>>194
>手続きって何だ？
俺に聞くな、そんな事も分からないのか？ 本当にバカ？ 大丈夫か？
><完結した処理1>;
><完結した処理2>;
><完結した処理3>;
>こういうことだよね。
ぜんぜん違う。 なにも分かってないのか？
おまえ、駄目だ。
0197デフォルトの名無しさん
2010/04/24(土) 20:07:41アクターモデルだろう
一般にOOPってそういうものを言ってるのか？
Smalltalkですら違うと思うんだが
0198デフォルトの名無しさん
2010/04/24(土) 20:44:38それなんて構造的部分型？
0199デフォルトの名無しさん
2010/04/24(土) 22:49:25OO が嫌いな人は、全部の流れを一度に把握することにこだわっているんじゃないかな。
OO は、全体の設計をする時には部分の仕様を気にしないでいいようにするためのものだよね。
0200デフォルトの名無しさん
2010/04/24(土) 23:15:25あと、部分を実装する時に、他の部分の実装を気にしなくても済むのもメリットだね。
「オブジェクト同士の依存関係で破綻する」という反論が来るかもしれないが、
実装の前に、オブジェクト間でそういう依存関係を持たないように設計するのは大前提。
そもそも、「全部の流れを一度に把握する」などというのは、大規模になるほど不可能になる。
0201デフォルトの名無しさん
2010/04/25(日) 03:25:04OO の世界では、自分の責任範囲でないデータのアクセスはたとえ１行で済む内容でも責任者を呼び出すし、
呼んだ先で何が実行されているかわからない（わからなくていい）形になる。
全部の流れを一度に把握することに拘っていると、OO は嫌いになるだろうな。
0202デフォルトの名無しさん
2010/04/25(日) 03:32:280203デフォルトの名無しさん
2010/04/25(日) 09:53:50"とんでもなく"までは、遅くならないが
構造化より遅いのは確か。
でも、その構造化も非構造化より遅い。
速さを追求したいなら、GOTO文を多用すればいい。
0204デフォルトの名無しさん
2010/04/25(日) 11:11:580205デフォルトの名無しさん
2010/04/25(日) 12:42:41お前分かってるね。
>>179 = >>196 は、OOPすらよく分かっていない。
その癖声だけ大きい。こういうのがOOPの評価を無駄に落としている。
だから俺はOOPを嫌いになったし、距離を置きたくなった。
それからActorモデル、こういうのは、
カーネルからのアプリのエントリーポイントのキックなど、
呼び出し元のコードが一切触れない、変更できない、再コンパイル出来ない、
制限の元で「仕方なく」使われるもので、
好き好んで使う奴は居ないと言うこと。
> 管理するとか、本当にバカだな、管理すると言う事は主従関係だぞ。
この発言も面白かったな。
ソフトウェアエンジニアと、プログラムの関係が主従関係なのは当たり前だろ。
彼の中ではプログラムと人間が対等だったりするのだろうか。ｵｰ怖い怖い。
だいたい、コンピュータってのは、奴隷の代わりに発明されたものでだな。
0206デフォルトの名無しさん
2010/04/25(日) 13:06:33それはカプセル化であって、OOPではないわな。
そんで次はこういう方向へ話が行く。「だったらOOPって一体何よ」ってね。
そんで、カプセル化とポリモを合わせ技にして、「オブジェクトの振る舞いを定義して～」って話になる。
このようにOOPの用語は極めて曖昧で、そもそも議論が成り立たない。
なぜこんなことになるかというと、それは、ポリモとカプセル化の構文が同じだから。
カプセル化のついでに、同じところにポリモも押し込んだから。
なんだかよく分からない状態だから、OOPとか言って抽象的にしてお茶を濁す。
挙句の果てにパラダイムシフトとか適当なことを言い出す始末。
事態を改善するためには、機能ごとに構文を分ければよい。
俺はこう分けた。
カプセル化 → 構造体へのアクセサ。C++での非仮想メソッド。
ポリモはしない。構造体なりをアトミックに扱うための機能。
ポリモ → 関数の動的オーバーロード。ポリモ目的。
目的と手段の対応が明確なので、OOPとかいった変な言葉も、パラダイムシフトも必要ない。
(パラダイムシフト(笑) この場合ズレてるってことだよな )
C言語の正統な拡張、本来あるべきはずだったC++の姿と言えるね。
0207デフォルトの名無しさん
2010/04/25(日) 13:47:21構文をどう呼称するとかどうでもいいから、
君が提唱するそれが、開発の容易性にどう貢献するのか論証してくれ。
0208デフォルトの名無しさん
2010/04/25(日) 13:57:19> だいたい、コンピュータってのは、奴隷の代わりに発明されたものでだな。
それは何の話？
計算尺？そろばん？ 階差機関？ チューリングマシン？ ABC？ ENIAC？
それとも、どこか別の並行宇宙での歴史の話をしてるのかな。
まぁ、そろばんを「奴隷」と呼ばわる趣味があるのなら止めないけどね。
0209デフォルトの名無しさん
2010/04/25(日) 14:06:26独立して存在する各オブジェクト同士が、互いにメッセージ投げ合って、互いに協調して、動くという、
いわゆる、アクターモデルがある。
プログラムがまるで何かのシミュレーターみたくなってる奴な。
しかし、オブジェクト同士の化学反応の結果が、目的の機能になってなきゃならないってのは、
シミュレーション自体が目的の場合を除き、誰がどう考えても遠回り。
こういうのはOOPすら良く分かってないし、思考回路が壊れてるから精神科に行ったほうが良い。
> 「オブジェクトが主体的に動くもので」
こう言うこと言い出す奴には、なるべく近づかない事だ。火傷するぜ？
追い詰めるとﾌｧﾋﾞｮり出すからな。放っておくしか仕方ない。
そのうち自分で気づくさ。何が大切なのか。
0210デフォルトの名無しさん
2010/04/25(日) 14:12:20そろばんは逐次実行できないよね。
いわゆるコンピュータには、なぜプログラムカウンタがあるのかを考えてみよう。
0211デフォルトの名無しさん
2010/04/25(日) 14:12:27> シミュレーション自体が目的の場合を除き、誰がどう考えても遠回り。
そんな風に考えるのは君だけなので、勝手に他の人間を巻き込まないように。
論理的に考えられない奴ほど、「みんなが言ってるから正しいに決まってる」とか言いたがるよな。
> そのうち自分で気づくさ。何が大切なのか。
言ってることが、どっかのスピリチュアル（笑）な宗教の教祖と変わらんな。
プログラマなら、主張は具体的かつ論理的に書いてくれ。
0212デフォルトの名無しさん
2010/04/25(日) 14:17:00「逐次実行」の定義は？
0213デフォルトの名無しさん
2010/04/25(日) 14:20:13と事前に稀な事例であることを断ってるだろ。
でも、そういう落ちこぼれを生んでしまう危険性がOOPにはあると思う。
たぶん、「オブジェクトの振る舞いを定義して～」ってのがマズいんだろうな。
この、お茶を濁した大人の発言を、本音と建前の分からない奴が、
変な風に都合よく解釈しちゃうのだろう。OOPに罪があるわけじゃないんだけどね。
0214デフォルトの名無しさん
2010/04/25(日) 14:22:34> 「時々OOPである糞な例として、」
日本語でおｋ
0215デフォルトの名無しさん
2010/04/25(日) 14:22:54お前らは俺を玩具にしたいだけなんだろ。
0216デフォルトの名無しさん
2010/04/25(日) 14:25:36> お前らは俺を玩具にしたいだけなんだろ。
何その萌えキャラｗ
ちなみに俺は>>197だが、レスあんがと
>>178にもレスくれると嬉しい
0217デフォルトの名無しさん
2010/04/25(日) 14:34:52君の発言がことごとく論理的でなくて解釈に困るから、いちいち確認を取らざるをえないだけ。
「逐次実行」発言にしたって、「記憶されたプログラムを解釈して」逐次的に演算を行う、という意味なら、
「プログラムを記憶する」の部分はコンピュータの利便性を高めるために提案されたものであって、
計算機という存在の本質ではない（例えば、最初期の真空管コンピュータはストアード・プログラム方式ではなかった）。
0218デフォルトの名無しさん
2010/04/25(日) 15:00:01自分が拠って立つモノが、根本的にどんな原理に基づいているのかに無頓着だし、
だから、それがどういう由来（歴史）で形成されてきたについても全く無関心。
その上、自分の狭く偏った視野に固執し、新たな概念に学ぼうともしない。
これなら、君が嫌いであろう単なる新しモノ好きの方が、技術屋としてはよっぽど「使える」。
0219196
2010/04/25(日) 15:37:12>「主体的に動くオブジェクト間のメッセージパッシング」って
>アクターモデルだろう
アクターモデルもメッセージパッシングを使うが
メッセージパッシング＝アクターモデルではない。
http://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%83%91%E3%83%83%E3%82%B7%E3%83%B3%E3%82%B0#.E3.83.A1.E3.83.83.E3.82.BB.E3.83.BC.E3.82.B8.E3.83.91.E3.83.83.E3.82.B7.E3.83.B3.E3.82.B0
>一般にOOPってそういうものを言ってるのか？
>Smalltalkですら違うと思うんだが
一般的なオブジェクト指向言語は処理の並立性は保証していないし
ターゲットのマシン・OS自体も並立処理に不十分で、アクターモデルではない。
それに、オブジェクトを使う時に
１．インスタンス作成
２．メソッド実行
３．インスタンス破棄
と、基本的に逐次的に実行しないといけない。
しかし、すくなくともメソッド実行はメッセージパッシングを目指すべきだ。
「Smalltalkですら違う」それは、プログラマーの問題で、言語の問題ではない。
それに最初のオブジェクト指向言語Simulaは、メッセージパッシングだ。
0220デフォルトの名無しさん
2010/04/25(日) 15:40:320221デフォルトの名無しさん
2010/04/25(日) 15:45:07逐次実行可能な(プログラミング可能な)物を指していると言うことぐらいは分かるだろうよ。
プログラムのスレでプログラミング不可なコンピュータ、まして、ソロバンの話をするわけ無いだろう。
>>216
実行時エラーでいいと思う。もしくは何もしないか。
0222デフォルトの名無しさん
2010/04/25(日) 15:49:13なに言ってんだこいつ。
>>197は、メッセージパッシングについてではなくて、
「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
メッセージパッシングなんぞ、どうてもよい。
0223デフォルトの名無しさん
2010/04/25(日) 15:59:59レスあんがと
どうもポリモーフィズムに関する事柄は完全に動的型言語っぽい形になるようだね
それはそれでアリだが
そういう方向だと、C++やJavaが使われている領域で代用するのは厳しいんじゃないの
っていうかぶっちゃけCLOS？
俺個人の考えを言うと、静的型の言語では、
型安全でコンパイル時に確定可能な静的ポリモーフィズムで十分な部分は
静的ポリモーフィズムを用いるべきだし
動的な部分は、TypeErasureみたいなテクニックを言語のレベルで綺麗に
取り込んで、型安全なダックタイピングが実現できればいいなと思う
そうなってれば、伝統的なISA継承によるポリモーフィズムは要らない
0224デフォルトの名無しさん
2010/04/25(日) 16:07:270225デフォルトの名無しさん
2010/04/25(日) 16:08:24どちらにしろ、いわゆるフォン＝ノイマン・アーキテクチャ登場以前の
アナログ・コンピュータを含めたコンピュータの歴史のどこをどう切っても、
「コンピュータは奴隷の代わりに発明された」なんて話は出てこないけどな。
0226デフォルトの名無しさん
2010/04/25(日) 16:12:56> こういうのはOOPすら良く分かってないし、思考回路が壊れてるから精神科に行ったほうが良い。
ダン・インガルスもアラン・ケイも重症患者にされそうな勢いだな。（もちろん反語的に）
- Smalltalkの底を流れる設計思想
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24
- 「ソフトウェア工学」は矛盾語法か？
http://metatoys.org/oxymoron/oxymoron.html
0227デフォルトの名無しさん
2010/04/25(日) 16:13:42コンピュータは当時の戦争で弾道計算に利用されていた
手回し式計算機を置き換えるものとして開発されたんだが？
それをまわしてたのは奴隷だぜ？
0228デフォルトの名無しさん
2010/04/25(日) 16:15:00CPUの本質はプログラムカウンタじゃないからw
0229219
2010/04/25(日) 16:26:00>「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
なにが、言いたい？お前「主体的」の意味が分かってないのか？
もしかして、「自立的」とか「自律的」と間違っていないか？ お前は「小学４年生」かｗ
お前は、もういいよ。
0230デフォルトの名無しさん
2010/04/25(日) 16:28:17「弾道計算 奴隷」でググってみたが、そんなソースは見当たらないぞ。
仮にその話が本当だとして、奴隷という動力の置き換え先は「電力」だろ。
どの道、道具を奴隷呼ばわりするタイプの人とはあまりお付き合いしたくないが。
0231デフォルトの名無しさん
2010/04/25(日) 16:31:400232デフォルトの名無しさん
2010/04/25(日) 16:33:24>>229
これｗｗｗ
0233デフォルトの名無しさん
2010/04/25(日) 16:40:20個人的にはダックタイピングもメソッド名をそろえなきゃいけない制約がうざいかなぁと思ってる。
似た機能のメソッドが同じ名前でなきゃ駄目ってのもなぁ。
TypeErasureであれなんであれ、結局アダプタクラス作るわけで、なんかスッキリしない。
しかし、動的オーバーロードの型安全性か。たしかに課題だなぁ。
実は静的に型安全性を保障できないと言うわけでもないんだけど、(リンク時にエラーとすることは可能)
マルチメソッドは組合せ爆発が起こるから、
実際には利用されない引数の組み合わせなんかも有ったりして、その辺がネックだなぁ。
0234デフォルトの名無しさん
2010/04/25(日) 16:55:00なんでだよ。アクターモデルのアクターは自律しては動かないだろ。
勝手な妄想はよしてくれ。
> 「主体的に動くオブジェクト間のメッセージパッシング」って
> アクターモデルだろう
元の文はこれだろ？
お前は何でこれの「メッセージパッシング」だけを拾ってきて、
> アクターモデルもメッセージパッシングを使うが
> メッセージパッシング＝アクターモデルではない。
とか言ってんだよ。そりゃメッセージパッシング!=アクターモデルなのは自明だろ。
0235デフォルトの名無しさん
2010/04/25(日) 17:05:220236デフォルトの名無しさん
2010/04/25(日) 18:00:21http://metatoys.org/oxymoron/oxymoron.html
今ここ読んできたけど、マジだな。
はぁー、こういうのに感化されるわけか。大変だな。
まー俺なんかは素直なもんだから、
手続き型言語と対立するのはLISPなどの関数型言語やSQLなどの宣言型言語だと思うし、
対抗馬にOOPを持ってこようとは思わないがなぁ。
インターネットがどうとか言ってるが、
インターネットが、ほんの僅かの単純な機能を成り立たせるために、
一体どれだけ複雑なシステムになってしまっていることか。
そこには粒度の問題があって、はたしてこれは言語レベルでサポートする必要はあるのかね。
小さな粒度では無駄に複雑になるだけだし、大きな粒度ならCで書いても十分だし。
0237デフォルトの名無しさん
2010/04/25(日) 18:12:13> インターネットが、ほんの僅かの単純な機能を成り立たせるために、
> 一体どれだけ複雑なシステムになってしまっていることか。
目の前の問題を短絡的に解決するだけの技術だったら、
ここまで色々な使い方を容れられるインフラにはならなかったよ。
人が構築物を作り上げるのに「神」の視点をもってすることの愚かさを知るべき。
> しかしまたこれらの発明者たちも、これらの問題を直接ゴリ押しでは(「神」のようにという
> 言い方も出来る)解決出来ないと感じる程度に賢明だった。その代わり、このような問題
> に対する巧妙な手口を見つけ出したのだ。兵術の前に策略を用い、失敗を回避せずに
> 受け止める事だった。
0238デフォルトの名無しさん
2010/04/25(日) 18:24:09アランケイのその文章ってSqueakの文系的宣伝だよね？
SunがJavaに関して吹きまくっていたハイプとそっくりだわ
0239219
2010/04/25(日) 18:24:39自分で書いたことも忘れたのか？
>>222
>「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
見苦しい、いくら言い分けしても、お前が「主体的に動くオブジェクト」を
アクターモデルと考えたことに変わりない。
>>235
>日本語力に問題がある奴と話をするとほんと疲れるな。。
日本語が得意なお前に質問だ。 日本語が得意なお前なら分かるよな。
>「主体的に動くオブジェクト間のメッセージパッシング」って
>アクターモデルだろう
この場合の述語「アクターモデルだろう」が指している主語はどれだ？
①「主体的に動くオブジェクト間のメッセージパッシング」は、アクターモデル。
②「主体的に動くオブジェクト」は、アクターモデル。
③「オブジェクト」は、アクターモデル。
④「オブジェクト間のメッセージパッシング」は、アクターモデル。
⑤「メッセージパッシング」は、アクターモデル。
お前は、書いた”本人”じゃないのに、⑤「メッセージパッシング」は間違いで
②「主体的に動くオブジェクト」と決め付けた、なぜそれだと思った？
詳しく説明してくれ。
0240デフォルトの名無しさん
2010/04/25(日) 18:45:22人間は分業したからこそ、ここまでの技術力を持ったんだよなあ。
0241デフォルトの名無しさん
2010/04/25(日) 18:49:020242デフォルトの名無しさん
2010/04/25(日) 18:55:09少なくとも、問題領域を分割して分業するための優れた方法ではある。
唯一の方法だとは誰も言っていない。
0243デフォルトの名無しさん
2010/04/25(日) 19:35:45そりゃすまんかった
もう少し、具体的に例でも出して問題意識とか得意不得意を挙げていかないと
建設的な話に転がっていかない気がするよ
哲学だけじゃ腹の足しにはなりゃしねえ
ttp://www.sampou.org/haskell/article/whyfp.html
これはただの宣伝文じゃなくて、少なくとも具体的だ
0244デフォルトの名無しさん
2010/04/25(日) 19:40:56> 具体的に例
デザインパターン。
0245デフォルトの名無しさん
2010/04/25(日) 19:53:11デザパタから始めるのは視野が狭い
たとえば関数型なら、状態を扱うデザパタの多くは問題外だろう
0246デフォルトの名無しさん
2010/04/25(日) 22:10:590247デフォルトの名無しさん
2010/04/25(日) 22:24:47kwsk
0248デフォルトの名無しさん
2010/04/25(日) 22:49:240249デフォルトの名無しさん
2010/04/26(月) 11:08:43正確には「デザインパターンの大部分はバッドノウハウである」じゃないでしょうか。
>>247
関数型言語なら状態を扱うデザパタは不要です。
動的型言語なら静的型言語の制約を緩めるデザパタは不要です。
GoFデザインパターンの大部分はC++やJavaが手続き型で静的型だから
必要なのであって他の言語であればそもそも不要だから
C++やJavaに固有のバッドノウハウです。
0250デフォルトの名無しさん
2010/04/26(月) 18:23:10> >日本語力に問題がある奴と話をするとほんと疲れるな。。
> 日本語が得意なお前に質問だ。 日本語が得意なお前なら分かるよな。
あーごめん、それ書いたの俺じゃないんだ。
お前普通に痛い子だから、多分あちこちに敵が居るぞ。
いいかげん、お前の面倒見るの大変だから、さっさとお仲間さんのところへ行ったら？
>>237
いや、そうなんだけど、なんて言うかな。
インターネットってすげぇ壮大な仕組みだけど、
最終的な機能だけに着目すれば、データのコピーが出来るだけ。
C言語で言えばmemcpy相当。
インターネットの猿真似すりゃ、memcpyですら、あんな壮大になってしまうわけで、
よほどの制限が無い限りは真似すべきじゃないよね、って話。
インターネットは色々な制約の元、ああいう形態になってるわけだけど、
それらの制約は今の自分たちには、課せられてないかもしれない。
だから、インターネットを持ち出してOOPの有用性を語るのはナンセンスかなぁと。
0251デフォルトの名無しさん
2010/04/26(月) 18:31:44静的型言語はアレはアレで有用なんだけど、
C++やJavaで、中途半端に仮想関数なんぞ取り入れたのがマズかったんだろうな。
失敗作ってことで。
0252デフォルトの名無しさん
2010/04/26(月) 18:38:18実用性を全く考えないアカの人ですか？
■ このスレッドは過去ログ倉庫に格納されています