[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