Re: [Xen-devel] Xen Management API Draft, version 0.4

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Fri, Jul 07, 2006 at 02:49:10PM +0100, Harry Butterworth wrote:

> > > 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.

I happen to agree very much with the document that you have cited, and I have
been writing Java and C++ code without getters and setters for many years.

That said, I don't think that that approach is suitable here.  Every one of
these use cases that we are using to drive the dynamic model has the
additional caveat that the system must be permanently monitorable.  In other
words, this API isn't just for _doing_ things, it's for watching what's going
on, too.  This means that you need access to every field that we've exposed,
all the time.

Furthermore, this approach implies that it's possible to enumerate all your
use cases.  This is all very well within a program, when you can add a new
method to an object when it becomes necessary, but this API doesn't have that
luxury -- it must be possible to support arbitrary and unanticipated use cases
without coming back and forcing additional methods upon the API.  This means
that all the fields must be available directly and through the API.

Cheers,

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel