[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:12151] Re: historical info
樽石です。
At Fri, 22 Jan 1999 02:32:58 +0900,
Mitsuru Oka <oka@debian.or.jp> wrote:
> 樽石> それは、問題なのでしょうか?
> 樽石> 他に対して「作用」を要求するのはごく一般的だとおもいますけど。。。
>
> 確かに一般的に見うけられます、それに馴染んでしまうと僕の書い
> てる事はちょっと遠回りに見えます(実際遠回りですが)。例えば、
> 手続き型と宣言型を思い浮べてみたらちょっと分かるかも。今の
> postinst あたりは手続き型の典型ですが、じゃなくて、もっと抽
> 象化した要求ないしは条件を記述するに留めるんです。パッケージ
> の性質を宣言する。
>
> # 当然、{pre,post}{inst,rm} なんてカテゴリは不必要になります。
> # いつ何を実行するかは、システムが考えることですから。
僕は、現在の dpkg を 2 段階に分割して考えています。システムの
関係、状態を保持、適用するのが 1 つ。そしてパッケージのインス
トール等の作業を実際に行う側です。パッケージのインストール側は
パッケージ依存部手続き(多態性部)を、インストール寸前まで未解決
のまま残しておいて、実際にインストールが始まる時にその部分を動
的にロードします。これが今の {pre,post}{inst,rm} です。これらは
前の Java による実装で書いてますが、クラス「パッケージ」の public
メソッドです。図示すると
<システム>.dpkg-divert, <システム>.update-alternatives 等へのインタフェース
|
+--------+ <-----------------------------------+ |
| | +-------------+ | |
|システム| (1) |インストール | |<---+
| 情報 | <------ |(必要時に (2)| |
| | |呼ぶ)--> ◯ <------+ |
+--------+ +-------------+| | | a class implementing Package
| +=======+ +--+-------+--------+ |
+===============+==========+ |{pre,post}{inst,rm}|<---+
| +-------------------+
現行のdpkg
(1) dependency check、 展開要求、 エラー例外等の取得
(2) 他態性部インスタンス
つまり、 (2) は手続きでなくて、オブジェクトではないか
と思っているのです。
#とは言っても現行の preなんたら は単なる手続きとしての
#役目しか果たしていないのは問題ですが…
> > カプセル化の実体こそ、ルール記述(=データ)と制御(=手続き)の明
> > 確な分離です。オブジェクト=データ+手続きと言うと、よく、両者
> > をごちゃまぜにすることと混同される方がいるようですが、混ぜる
> > のではなくて明確に切り分けて考える行為です。
>
> 樽石> 岡さんがいうルールと制御の分離はカプセル化を念頭においてる
> 樽石> ものなのでしょうか?僕は、ルールはルールとして、dpkg に処理
> 樽石> させて、そのあと制御を実行するという分離を言っているんだと
> 樽石> 思っているのですが。
>
> 樽石さんが書いていたのにちょっと反論して書いただけで、カプセ
> ル化を意識しているわけではないです。それよりむしろ、いかにデー
> タフォーマットたり得るか、を考えています。例えて言えば、
> PostScript と PDF、DynamicHTML と XML(as Web Data) って所
> でしょうか、対極的でしょう? # 言葉少なすぎるかな...。
つまり、パッケージはデータ部のみを持つものにしようってことですね。
僕は、パッケージはデータ部と他へのインタフェース(そしてまた、dpkg
側もデータ部と他へのインタフェース)を持っているべきだと思って
いるのです。つまり、現状の {pre,post}{inst,rm} は、dpkg から パッケ
ージへのインタフェース、dpkg-divert 等は、dpkg へのインタフェースです。
> 樽石> これは、予想外の行動もできるという意味で問題なんでしょうか?
> 樽石> それとも、パッケージ側には全く実行を許さないということでしょうか?
>
> そんな所です。あと、うまく説明できない何かがあるんですが...。
> 例えば、パッケージにバグがあるとよく、次のバージョンの
> postinst あたりで対処したりしますが、あれが癌なんです。もっ
> と問題を直視できる方法はないものか、と。
ふむ。
#うーむ、授業がはじまってしまうのでこのへんで。
-------
電気通信大学電気通信学部情報工学科 3 年
--University of Electro Comunications Junior ---
樽石 将人(Masato Taruishi)
E-mail:taruis-m@xxxxxxxxxxxxx