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

[b-free: 1210] Re: オブジェクト指向の OSへの適用(Re: スケジュールについて)



つづき。
# 大分間があいたけど。


Ryuichi Naitoh wrote:

> > 実際には、(もしOOにすると言うのなら)
> >  1.class 間の関係で、OSの内部を理解(再認識)する。
> >  2.class 間の関係から、class に必要な interface を定義する。
> >    重複があれば、継承や所有による単純化を考える。
> >  3.interface と class から、module を考える。
> >    module は、class の為に何を提供したらいいのかを考える。
> >    class が module のよりどころになる可能性あり。
> >  4.module の提供する物が決まれば、自然と、内部でとれる
> >    選択肢が限られてくる。
> >
> > こんな感じです。
>
> えーと、これだと全然イメージが湧かないのですが、もう少し具体的に説明し
> ていただけませんか?
>
> 想像するに、すでに非オブジェクト指向な OS があるという状態で、オブジェ
> クト指向言語で書き換えるということを考えているみたいですね。

いえいえ。(もしかしたら Non-object oriented な言語で)OSの内部をOOで構成する話をしてい
るのです。
class 分けとかというのも、実際の class の code を書くのではなく、想定するのです。
BTRON2でも、「実身・仮身」という立場で大きな class 分けをしていますが、実際にそう言う
class を書くわけではないでしょう? 話はもっと、抽象度の高い話なのです。

> 単に処理をブロック毎に分け、ブロック間のインタフェースを制限するだけな
> らば、オブジェクト指向である必要はないと思います(というか既存の構造化
> プログラミングの範疇に入ってしまう)。OS が使うデータ型で親子関係にある
> ものが少ないことを考えると、継承というオブジェクト指向言語の機能も使う
> 必要もないですし。

えっと、data type を新たに作ります。「class 間の関係でOSをとらえ直す」というのは、data
type(class) をOS構造から抽出するのです。で、その抽出された class 同士の関係から、module の
割り振りが自然と決まっていく物だと思います。

> > ただ、thread と class の関係は、Java を見れば分かるように単純ではないので、module の割
> > り振りはしんどいかもしれません。
>
> ?

これについては、たとえば、java は thread を class として完全に定義できていません。だから、一
つの class method が、いくつもの threads に共有されたりします。

# その辺が未だに、僕が java で trouble にあたる所なのですが。

data(class) というのは、元々、code(process) とは対局にある物ですから process を class で表現
すると言うことはなかなか難しい物があるのだと思います。たとえば、process の current context
は、一つの class を構成しますが、実際の execution code は、その process class にどのように所
属しているのかという問題があります。Java の場合は、code を Thread class から基本的には分離し
ました(Runnable interface で)。一般的な C++ では、process を class としては扱わないようです
(class の外にある)。class の member function として、そう言った全体の process code を所属
するという方針は単純ですが何か不適切な気がします。

# 何故かはよく分かりませんが、何となく。


> > > さらに、オブジェクト指向の場合、ライブラリ化が重要になります。このオブ
> > > ジェクト指向のライブラリについては、使う方も作る方もそれなりの労力がか
> > > かります。使い物になるオブジェクトライブラリを作るには、2、3年かかるで
> > > しょう。ソースの量も、数万ステップを越えるものになります。
> >
> > この件については、OSがOO化された場合、大分低減されると思います。
>
> そのココロは?
> OS が OO 化されたからといって、自動的にクラスライブラリが作りやすくな
> るとはとても思えません。何か作りやすくなるような理由があるのでしょうか?

例えば、API が、overload を許したとしましょう。そうすると、多くの class member function で、
同じ API を使うようになります。すると、それは多くの code の重複を生みます。重複があるという
事は、継承や template による coding の大幅な削減が期待できます。

OSが exception handling 用の stack を提供したとしましょう。これによって、exception
handling の為に stack に特別な処理をする必要が無くなり、compiler の修正が少なく単純になりま
す。

OSが RTTI を支援したとしましょう。そうすると、compiler の dynamic_cast に関する処理がだい
ぶん楽になります。

などなど。


> 今回の議論では、クラスライブラリの対象として、アプリケーション側のクラ
> スライブラリと OS 側のクラスライブラリの 2 つがあると思います。

どちらも、僕は話していません。そもそも、class library という物自体が、開発環境の話ではないで
しょうか?

> 坂村先生自体はオブジェクト指向が好みじゃないみたいですね ^^)
> BTRON2 は、Generic 関数としての API がありますが、ちょっとオブジェクト
> 指向とは違う気がします(クラスもないし、もちろん継承もない)。
> データ抽象レベルのものではないですか?

えっと、generic 関数としての API を実現するために、なかで、OO的な処理を必要とする気がしま
す。具体的には、各 object が自分に対する情報(自分が何者か。例えば、process だとか実身だと
か)を持っていて、そこに、API を使うという手段で、message(例えば、open)を与えてやると、
object 自身が適切な処理を選択するという外観です。


> しかも、作り直しには、ある程度使われたフィードバックが必要になります。

作り直しは、design の中で、大分、軽減されると思います。
作り直すとは、詳細な API の仕様を検討する間に、つじつまを合わせるという作業を言いました。

>  確かにインタフェースを変えなければ、内部を作り変えても大丈夫というのが
> オブジェクト指向の長所ですが、クラスライブラリのクラス階層を変えるよう
> な大きな変更には、やっぱりアプリケーションも影響が出ます(というよりちゃ
> んとやるには、アプリケーションも作り直しが必要)。

こういう問題があるので、design の段階が非常に長い時間を必要とするのだと思います。

-Aki.