








オブジェクトの受動性
まず、スレッドとかとの違いという意味で。
オブジェクトは、常にそうでないとならんって訳では無いだろうけど普通は、
自発的に「自分の時間」をがんがん先に進めていくもの、としては作られないようだ。
スレッドやプロセスとは、その辺が違う(ことが多い)。
きっかけの問題として。
要するにイベントだ。メッセージとも言うが。
これがオブジェクトに「よこされる」と、そのオブジェクトは「応答」する。
言い換えれば、放置されりゃ何も起きない、という感じか。
ビリヤードが似ているような気がする。
1つの球を突く(=イベント)。球が動く(=メソッド処理)。
すると球が他の球に当たる(=イベントがイベントを呼ぶ)。
そうして沢山の球が動く。
この連鎖のうち、ユーザが直接意識してない部分(ユーザのキューの一突き以外)については、
あたかも「自動的に」動いているかのように見えるが、
そのきっかけの元を正せば、ユーザの一突きに由来する。
…というモデルだな。
そして勿論、摩擦もとい計算機停止問題に基づいて、
その連鎖はいつか止まる(止まらないことも有るわけだが)。
止まったら、また次に突かれるまで、永遠にそのまま停止だ。
#ところでポケットに落ちた球は、ガベコレされたのかな?(違
ってことは、そういった球(オブジェクト)がいっぱい有る空間を
駆動するためのスレッドが、単に外付けされていればいいわけだ。
しかもスレッドの個数は典型的には1つで十分だ。
全体に平等(笑)に時間が与えられるならば、時計は全体に1つ有れば十分なので。
オブジェクト自体が自分の時間を司る、という仕掛が必要ってわけじゃない、と。
それどころか球は、時間を時間として意識する必要すら、無いかも知れない。
単に、ぶつかられたら応答すれば良いのであって、その応答の仕方の時間への依存の仕方次第では、
いちいち時計を参照する必要すらないだろう。
なお余談だが、多数の球がぶつかりあって動くさまは、
それこそユーザには予想(意識?)不可能なほど複雑な事もしばしばだろう。
球どうしの位置関係によって、動きは千変万化する。
実は、プログラムの「難しさ」ってのは、かなりこの点に由来するんだが。
つまり、要素間の繋がり具合が多彩かつどんどん変化するので、
人間の意識では簡単には追いきれないのな。
構造化がどうのとか言っているが、それにも限界が有るんじゃないかな。
完全にこの複雑さを追い詰める(撲滅ないしは支配する)ことは、出来ないような…
だったらせめて、今どうなってるか、直前にどうだったか、直後にどうなったか、が
「見える」ようには、なっていて欲しい。
どこに分類したものか判らない(良いページ名が思いつかない)ので、とりあえずここに書いておく。思いついた人は移動よろしく: -戯
#つまり、これを書くべきページ名が判ったなら、それが疑問自体の答えになるのだと思う(^^;
2chの「理想の言語を語ろう」(Googleで「ローカルスタック コルーチン」で引いたもの。Cacheしか見つからなかった)の 2 氏の主張がよく判らない。
一通り下まで読んだつもりだが、この人(?)が示してる範囲の事柄は、
Javaの虎本(随分昔ですね)ですら載っていた、 Source/Pipe/Drainモデルな(というかJavaに標準装備の)
Stream系クラスで無理なく実現できてるのでは?
ChainOfResponsivilityパターンとか、Decoratorパターンとか…
データを突っ込まれたら、(加工してから)次へ送る、という数珠繋ぎをやればいいだけのような。
つまり、たとえばPushモデルで設計するなら、自分は「次」への参照を持っておいて、
自分がputされたら、(加工してから)「次」のgetを呼び出せば済む話。
ローカルスタックもコルーチンも要らない。
どうしてもというならオブジェクトに継続(それが使える言語ならば)を持たせればいいんだろうけど、
そもそもこの程度なら、継続すら不要で、言語お仕着せデフォルトの共有環境で十分では?
少なくとも46の「現行のCALL/RET関係では、仕様変更で大幅にインターフェースが変わってしまう」は、なんか違うような。
クチ(つまりputメソッドとgetメソッド)の形状(Interfaceなど)さえ決めておけば、
後は各オブジェクトがそのクチと互換なクチを持てば済むのでは?
イメージ的にも何ら無理はしてないと思う。決められた形状のクチがついた色々な機械(フィルタ)という考えを
そのまま計算機に持ち込んだだけだもんなあ…?
このページを編集 (3907 bytes)
 |
以下の 1 ページから参照されています。 |
- 戯 最終更新: 2003-11-23, 13:37:47 <airh128>
This page has been visited 3585 times.