[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1222] Re: b-free: 1205についてのコメント (2/2)




隆一です。

From: Hideaki Suzuki <h1suzuki@bridgew.edu>
Subject: [b-free: 1215] Re: b-free:         1205についてのコメント (2/2) (Re:         オブジェクト指向のOSへの適用)
Date: Wed, 01 Apr 1998 01:22:45 -0500


...[snip]...

> 
> 
> > > > 私の書いたのは OS をオブジェクト指向言語でオブジェクト指向の機能を使っ
> > > > て記述する話とアプリケーションレベルのクラスライブラリの話です。
> > >
> > > 僕が「OSの上に、OOPな言語を被せる。」と言ったのも、そう言う意味でした。
> > > で、もう一つのOOは、OS自体をOOにするんですよ。
> >
> > OS をオブジェクト指向的に作るという考えは、感じとしては分かりますが、
> > 具体的にどういうものかと考えると、実装にバラエティがありすぎてちょっと
> > 分かりません。
> 
> そこを話し合って、可能性がどのくらいあるのかを見るのは良い「必要な労働力」の見積もりになると思いま
> す。
> 
> # 別に、可能性を見るのに一ヶ月なんて費やさないでしょうし。

で、その可能性を行う作業は誰が行うのでしょうか?
また、必要なプログラマの人数を見積もることができたとして、どうやってそ
のプログラマを集めるのでしょう?

結局、全然問題の解決になっていないような気がします。



> 
> > > その点、BTRON2は、まさに、OOなOSだと思います。
> >
> > 全然、前の文とのつながりが分かりませんが。。。
> > BTRON 2 の開発環境が非オブジェクト指向なので、BTRON2 はオブジェクト指
> > 向 OS ということでしょうか :-P
> 
> たはは。すごい取り方をしますね。(^_^;;;BTRON2の中身は、開発環境がどうであるにせよ、API の構
> 成から考えて Object Oriented っぽくなるだろうと言う話です。# 僕の頭の中での構成ですので、# い
> や、絶対違う!と言う人がいるかもしれません。
> # その場合、どうなるか聞きたいけど。
> 
> > あまりに、幅がありすぎます。設計法としてのオブジェクト指向ですか?
> > それとも、OS の構成としてのオブジェクト指向でしょうか?
> 
> OO 設計を採ると、OOな構成のOSになりませんかねぇ?

ならないんじゃないですか?
OS の構成としてオブジェクト指向というのが具体的にどういうことになるか
分かりませんが、オブジェクト指向な構成の OS というのは設計方針でなるも
のでしょう。




...[snip]...
> > # ほら、やっぱり、B-Free はオブジェクト指向ですね :-)
> 
> いえいえ。(^_^;;;
> 
> > ま、B-Free OS がオブジェクト指向である、というのは半分冗談ですが。
> > 処理とデータの両方を含むモノに対して、処理を要求するような構成になって
> > いればオブジェクト指向的だとは言えるわけで、プロセスやメモリという具体
> > 的なモノをシステムコールで操作するという見方をすれば、OS はオブジェク
> > ト指向的である見方はできます。
> 
> 具体的な物を「操作する」というのは、OOではないと思います。極端な例ですが、
> 
>   1+2
> 
> を、「1と2と言う対象を”足す”」と言った場合、今まで通りの見方で、「1に2+を送る」と言う見方を
> するとOOになります。(笑)

そうですよ。

Smalltalk はこういう考えで、数値計算をしています。
そのため、演算子の優先順位というのがなくなってしまいました。
(単純に左から右へ計算していくだけ。数値オブジェクトは、計算結果のオブ
ジェクトを返すようになっています)

これは、別に屁理屈ではなく、数値演算すら見方を変えることにより、オブジェ
クト指向として処理できるというコペルニクス的展開があり、それもオブジェ
クト指向が出たときの衝撃のひとつだったわけです。

ま、こういう考えは C++ などの純粋なオブジェクト指向でない言語だとなじ
みがないかもしれません。非オブジェクト指向言語にオブジェクト指向の機能
を追加した言語だと、数値計算は、非オブジェクト指向のパラダイムで解決し
てしまいます。

Smalltalk だと、さらに if 文のような言語処理系が処理するような構造文も
オブジェクト指向という枠組の中で解決しているので、この辺も調べてみると
面白いかもしれません。

結局、見方の問題も大きいわけで、オブジェクトというモノに対して処理が付
随していれば、これはオブジェクト指向になっている言うことはできます。
(ま、普通言わないですけど)



> > うーん、そうすると CLOS は、メソッド呼び出しの記述として (method
> > object1 object2) となっているので、オブジェクト指向とは言えなくなって
> > しまいます。でも、CLOS は、その名のとおりオブジェクト指向言語でしょう。
> 
> ぼくは、CLOS について良く知りませんが、上の例は、method に object1 & objec2 を送るという考えです
> か?だとすれば、まさにOOだと思います。

えー、違いますよぅ。

# って、思わず幼児語を使ってしまった。

method は、C++ でいうメソッドと考えてください。
メッセージ伝達というオブジェクト指向の考えかたは、CLOS ではなくなって
います(処理にオブジェクトを送るとは言わないでしょう)。オブジェクトの種
類によってメソッドの選択を行うという考え方で、メソッドの呼び出しを処理
しています。

そもそも、CLOS は Flavor の考え方を取り入れているので、こうなったよう
です。Flavor は、オブジェクト指向という考えを差分プログラムという観点
を重視して取り入れた Lisp 言語です(というか、Lisp の上に載っている言語
というべきか)。



> 観点は、渡す object によって、method に対応づけられた実際の code が変化(選択)されると言うことで
> す。method 自身が、何を送られるかによって、自分で判断して適切な処理を選択するのです。
> そのおかげで、programmer の方は、method の名前に頼った programming ができるようになります。

うーむ、鈴木さんは method をオブジェクトに見たてていますが、method は
あくまでも処理であって、オブジェクトではありません。メソッドが処理を選
択するという観点だと、すべてのメソッドのことを知っているスーパーメソッ
ドのようなものが必要になりますが、そんなものはないです。そういう風に考
えてしまうと、継承などを考えた場合に混乱します。

で、実際にどの処理を呼び出すかの選択は、処理系が行います。C++ で、同じ
名前の関数があった場合、引数の種類と数によって、関数を選択することがで
きますが、それと同じことです。



> > CLOS は処理の選択のキーとして、複数のオブジェクトが指定できてしまうし、
> > オブジェクトが処理を選択するという考えかたとはちょっと違うでしょう。
> > (処理を選択するものがオブジェクトとは別にあって、それが適切な処理を呼
> > び出すという感じ)
> 
> method と言いながらも、一つの抽象物を表現してしまっているんですね。

抽象物であるオブジェクトはあくまでもメソッドとは別の概念になっています。 
要は、メソッドは複数のクラスにまたがっているということです。メソッドの
定義はクラス定義とは別に行われます。

だから、CLOS について言えば、オブジェクトがあってそれに対してメッセー
ジ(メソッド)を送って処理「させる」という考えは無理があります。


> 
> > オブジェクト指向は、オブジェクトが処理を選択するものだけだという考えは、
> > すでにできなくなっていると思います。
> 
> この考え方は、まだ基本でしょう。
> 

ということで、オブジェクト指向といっても、すでにメッセージ伝達はオブジェ
クト指向であることの必須条件ではなくなっています。オブジェクトがメッセー
ジを受けとって、処理を行うという考え方は、Smalltalk からあるので、確か
になじみ深いですけど。

すでに、オブジェクト指向というパラダイムが世に出てから 20 年たっている
わけで、Smalltalk の考えによるオブジェクト指向という枠からはみだしたオ
ブジェクト指向言語もいっぱいあります(中には、クラス定義をしないオブジェ
クト指向言語もあるらしい)。そもそも、オブジェクト指向設計にしても、も
ともと言語という範疇に収まっていたオブジェクト指向を設計方法にまで拡大
したものです。




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