Re: Xen Management API Draft, version 0.4

[Harry Butterworth <harry@hebutterworth.freeserve.co.uk>]

> > I think this may be a bit unnatural and I think any required accessor
> > methods for constructor parameters are just a special case of accessor
> > methods required in general and they in turn are just a special case of
> > general purpose methods like the ones required to drive the vm
> > lifecycle.
> 
> You've lost me.  Could you give an example?

>From my understanding of your doc:

Class X has property Y implies constructor for class X takes parameter Y
and class X automatically gets at a get_Y method (and a set_Y method if
Y is RW).

But, what if the dynamic model for X has two states (say) where get_Y is
a valid operation in state A but not in state B.

An alternative way of saying this is that accessor methods are identity
state transitions on the dynamic model which happen to either pass or
return a single value and should be expressed in the same way that the
methods for the other state transitions are expressed.

i.e. little circular arrows that point back to the same state on the
dynamic model.  The key point is that they aren't necessarily valid in
all states of the dynamic model.

So, I think that the bit in the document about an object having a list
of fields is unnecessary and breaks encapsulation as explained in the
googled reference I gave.

You need to use the use cases to get the dynamic model for the objects
right and then work out whether any accessor methods are required at all
and if so, which states of the dynamic model they are required in.

Harry.