[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:12129] Re: historical info
本題の方の続きです。
In <19990117213114S.oka@debian.or.jp>
[debian-users:12010] Re: historical info (Re: Re:xf86-tt_updat...), Jan.17 '99 21:31 JST
oka@debian.or.jp says:
=
= 正常な状態の破綻は、オブジェクト指向における、クラス不変条件
= の破綻に似てますし、インストールやアンインストールの失敗/成
= 功は事前条件・事後条件と対応付けられそうです。
= # Eiffel から入った口なので...。
パッケージ間の依存関係は``has a'' で素直に表現してしまえばいい
として、もともとの話題だった時間経過に伴うパッケージ構成の変遷
はどう表現できるでしょうか。私はまだちょっとイメージがわかない。
とりあえず、構成の変更はリリースのタイミングでのものに限定して
考えてみる(hamm->slinkのような)として、たとえばhammのxbaseとslink
の「元xbaseだった」パッケージ群との間の関係をどのように表現しま
すか?
あと、競合関係の表現が意外とむづかしいと思うんですよ。
In <19990120214009R.oka@debian.or.jp>
[debian-users:12104] Re: historical info, Jan.20 '99 21:40 JST
oka@debian.or.jp says:
=
= それはそうかもしれませんが、スタックの底に溜ったものはゴミに
= なっちゃうんじゃないですか?? それなら Undo/Redo クラスが適材
= かも。古いのは適当に葬り去ってくれてもよさそう...。
そうですねー、状態を単にpushするのでなく状態差分をということな
らundo/redo で考えた方がいいんでしょうね。ただ、底に溜った物が
ゴミになるかどうかはどんな使われ方をするかにもよります。
ところで、インストール済パッケージの変遷についても履歴管理する
として、これとGCのアナロジを組み合わせるとすると、どうなるんで
しょうね。undo /redoとして管理されているパッケージ状態からの有
向グラフになるようにすればいいのかな。古くなってもういらなくなっ
た『状態』をぽいっと捨てるとそこだけに連なっていたパッケージが
ごそっと捨てられる... そんなかんじでしょうか。
-.- . -. -.
Ken Nakagaki <kenn@xxxxxxxxxxxxxxxxx>
「会社は主にそれ自身の慣性によって前進している」-- Gerry Spence