[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1215] Re: b-free: 1205につい てのコメント (2/2)(Re: オブジェクト指向のOSへの適用)
References: <35217B4F.43E9561C@bridgew.edu> <19980401132044P.night@soft.hitachi.co.jp>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
<res つづき>
Ryuichi Naitoh wrote:
> つまり、議論の前提となる B-Free の全体構成が必要ということでしょうか?
> それは、オブジェクト指向とは無関係な話ですね。
そこなんですよ。無関係じゃないんです。:-P
全体の構成の方法が、視点によって違ってしまうんです!
> > 良く思うのは、例えば、Memory Manager が提供する機能が「それで十分なのか、多すぎないのか、性
> > 能を何処で出すか、仕様上の欠陥はないか」とか、今一つ、全体の仕様の必然性に欠けるように見えて
> > しまうのです。その API が「何故」必要なのか、全体として「どう」機能するためにあるのか、とい
> > う理由付けが欲しいんです。
>
> これもオブジェクト指向とは別の話で、それこそ、この ML で具体的に API
> について議論すべき事でしょう。マネージャについて、「よくわからないから、
> 設計法からやり直そう」というのは、ちょっと説得力に欠けるのでは?
もし、OOで行かないのなら、もちろん、この ML で具体的にはなす話です。現実に、SMB の access right
に関する attr. については変更が利いた方が良いだろう事を僕は提案しました。僕にとっては、どちらにな
るか分からない現在、同時進行は当たり前でしょう。
# いまは、こっちの res のために保留してますけど。
ただ、そういった議論が、OOで行くとずっと減るのではと言っていたのです。なぜなら、API に必然性が生
じるからです。
> > > 私の書いたのは OS をオブジェクト指向言語でオブジェクト指向の機能を使っ
> > > て記述する話とアプリケーションレベルのクラスライブラリの話です。
> >
> > 僕が「OSの上に、OOPな言語を被せる。」と言ったのも、そう言う意味でした。
> > で、もう一つのOOは、OS自体をOOにするんですよ。
>
> OS をオブジェクト指向的に作るという考えは、感じとしては分かりますが、
> 具体的にどういうものかと考えると、実装にバラエティがありすぎてちょっと
> 分かりません。
そこを話し合って、可能性がどのくらいあるのかを見るのは良い「必要な労働力」の見積もりになると思いま
す。
# 別に、可能性を見るのに一ヶ月なんて費やさないでしょうし。
> > その点、BTRON2は、まさに、OOなOSだと思います。
>
> 全然、前の文とのつながりが分かりませんが。。。
> BTRON 2 の開発環境が非オブジェクト指向なので、BTRON2 はオブジェクト指
> 向 OS ということでしょうか :-P
たはは。すごい取り方をしますね。(^_^;;;BTRON2の中身は、開発環境がどうであるにせよ、API の構
成から考えて Object Oriented っぽくなるだろうと言う話です。# 僕の頭の中での構成ですので、# い
や、絶対違う!と言う人がいるかもしれません。
# その場合、どうなるか聞きたいけど。
> あまりに、幅がありすぎます。設計法としてのオブジェクト指向ですか?
> それとも、OS の構成としてのオブジェクト指向でしょうか?
OO 設計を採ると、OOな構成のOSになりませんかねぇ?
> > うーむ。Object Oriented の、Object が曖昧なので、僕は、今の B-free を Object Oriented なOS
> > とは認めたくないですねぇ。
> > たとえば、process も SMB も、ある種の共通する性格を持っています。例を挙げると、
> >
> > 1.生成できる。
> > 2.削除できる。
> > 3.Access 件を設定できる。..., etc.
> >
> > そこで、VolatileObject という抽象を規定して、process も memory もその一種だとしましょう。
> > もし B-free がOOなら、process と SMB に対して、全く同じ API で操作ができるはずです。その
> > API は、VolatileObject を操作できるという API です。こう云うのを、Object Oriented というのだ
> > と思います。
>
> それは、プロセスと共有メモリは、親子関係にないクラスだからです :-P
> オブジェクト指向だからといっても、無関係なクラスならば、操作は別になる
> のは当然ですね。
違います。同じ操作ができる場合、同じ種別だと考え、多重継承を行うのが基本です。
継承とは、親子関係ではなく、"is a kind of" の関係だというのが基本ですね。
# その点、所有は "has a" の関係と言われます。
> それに、プロセスと共有メモリは、クラスは別にした方がいいと思います。
> 鈴木さんは共通する性格を持っているということですが、プロセスと共有メモ
> リのそれぞれの操作はかなり違っていると思います。
> プロセスは、能動的なモノですが、共有メモリはプロセスから使われるという
> むしろ受動的な性格をもつモノです。むしろ、共有メモリというクラスに属し
> ている共有メモリインスタンスをプロセスに結びつけるようにするクラス構成
> の方がいいでしょう。
属しているというのは、どういう属し方かな。所有という事かな。
それは、process が所有するのはいっこうにかまいませんが、それは、process の特性ではなく、個々の
program の特性ですね。だから、process class が、SMB を所有するような interface を持つというのはお
かしな話になります。
林さんとのやり取りの中で、code も SMB のように扱ってしまったらどうかというのが、一瞬ありましたが、
結構 memory block w/ access protection と言う意味で、近いと思います。
特に、BTRON2のように、process を context のみと限定し、能動性を task として分離した場合、
process 自体は、よりいっそう SMB ぽくなって行くでしょうね。
> # ほら、やっぱり、B-Free はオブジェクト指向ですね :-)
いえいえ。(^_^;;;
> ま、B-Free OS がオブジェクト指向である、というのは半分冗談ですが。
> 処理とデータの両方を含むモノに対して、処理を要求するような構成になって
> いればオブジェクト指向的だとは言えるわけで、プロセスやメモリという具体
> 的なモノをシステムコールで操作するという見方をすれば、OS はオブジェク
> ト指向的である見方はできます。
具体的な物を「操作する」というのは、OOではないと思います。極端な例ですが、
1+2
を、「1と2と言う対象を”足す”」と言った場合、今まで通りの見方で、「1に2+を送る」と言う見方を
するとOOになります。(笑)
> うーん、そうすると CLOS は、メソッド呼び出しの記述として (method
> object1 object2) となっているので、オブジェクト指向とは言えなくなって
> しまいます。でも、CLOS は、その名のとおりオブジェクト指向言語でしょう。
ぼくは、CLOS について良く知りませんが、上の例は、method に object1 & objec2 を送るという考えです
か?だとすれば、まさにOOだと思います。
観点は、渡す object によって、method に対応づけられた実際の code が変化(選択)されると言うことで
す。method 自身が、何を送られるかによって、自分で判断して適切な処理を選択するのです。
そのおかげで、programmer の方は、method の名前に頼った programming ができるようになります。
> CLOS は処理の選択のキーとして、複数のオブジェクトが指定できてしまうし、
> オブジェクトが処理を選択するという考えかたとはちょっと違うでしょう。
> (処理を選択するものがオブジェクトとは別にあって、それが適切な処理を呼
> び出すという感じ)
method と言いながらも、一つの抽象物を表現してしまっているんですね。
> オブジェクト指向は、オブジェクトが処理を選択するものだけだという考えは、
> すでにできなくなっていると思います。
この考え方は、まだ基本でしょう。
>
>
> p----------------------------------------------------------------------q
> | FROM R.Night |
> | E-mail: |
> | rnaitoh@st.rim.or.jp |
> | Key fingerprint = 89 EB 77 95 40 C0 3C CC 37 A1 A7 FA 1C 66 FF D0 |
> b----------------------------------------------------------------------d
-Aki.