Heaviness of Q (Was: Re: [QUANTITY] Data Model for Quantity v0.5 - inheritance vs aggregation

[Martin @ ROE]

Brian Thomas wrote:

> 	Hi Martin,
> 
> On Monday 10 May 2004 11:27 am, Martin Hill wrote:
> 
>>By 'heavy' I really mean that we are strongly defining a lot of things
>>about what Quantity is, and therefore all the things that 'are'
>>Quantities have to carry around this extra baggage that might or might
>>not be relevent.
> 
> 
> 	Almost none of the components are "required" by either the interface
> 	or serialization, for example "accuracy". It is nevertheless usefull to 
> 	know that if you have an object that implements "Quantity" you can ask
> 	it "whats your dataType?" or "whats your units?" or "whats your accuracy?"
> 	(the latter providing a list of objects which each in turn implement
> 	quantity themselves).

I don't understand!  How can you say that accuracy is not required but 
can still be accessed?  If you are saying that we are making a general 
Quantity that might return 'nil' or might return an actual Accuracy, 
then we lose a lot of compile-time checking and gain nothing at runtime 
- because code that receives a Quantity has no idea whether it can 
really do what it expects with it or not.  When we are passing around 
objects that *should* have an Accuracy, then they should have an Accuracy!

> 
> 	If I understand your design correctly, you would deny VO programmers
> 	the ability to easily determine this sort of basic information that is needed
> 	to do scientific programming (!!). Without quantity as a interface/serialization
> 	that is used by other model elements, what is to rigorously keep 
> 	designers from deviating on how one might determine the coordinate
> 	System of X versus a model component Y which also has a coordinate
> 	system, but is specified in a different manner by another developer? 

No - maybe Dave B summarised it better.  I agree that we need to settle 
the basic information - I'm saying that where this is pulled together is 
not at Quantity, but in 'SED' or 'Image' or 'Flux' etc.  We can then 
insist that 'Flux' *always* has an Accuracy (if we so wish).

So in your example, I agree we need a common CoordSystem model.  But we 
shouldn't include CoordSystem model in all our quantites, because some 
don't need them.  And our model should reflect whether they are needed 
or not, rather than putting everything in the model and then letting the 
implementers work out whether it ought to be added or not.

>       And
> 	even if the components are the same object, there is not restriction on
> 	how each might create the methods for accessing that information, e.g.
> 
> 	public interface A {
>               public CoordSystem getMyCoordSystem();
> 	}
> 
> 	public interface B {
> 		public CoordSystem getAReallyImportantPieceOfInformation();
> 	}

Quite.  But if we agree a Pixel (say) object, then that will have the 
same property name for it's coordinate frame as all other Pixel objects. 
  If we then agree (say) a SkyObject model, then this (may) indeed have 
a different property name for the coordinate system to Pixel.  And this 
is fine, as we *should not* be attempting to do the same things to Pixel 
as to SkyObject because they are different things.

> 
> 	By realizing the Q interface, DM model components avoid the above situation.
> 	How does your approach prevent it?

I don't agree that the Quantity interface avoids the above situation, 
because the implementation now has no idea if it can really expect a 
CoordSystem or not.  My approach prevents it by being explicit in the 
model about what it is and where to find it, for whatever explicit class 
we are examining.

> 
> 
>>[snip]
>>
>>We must be careful that our interfaces don't end up being classes.  An
>>interface should (mostly) specify *behaviour*, not contents.  Specifying
>>a bunch of properties (as has been done for Quantity) is effectively
>>specifying a container class, even if you can technically say that the
>>properties are methods and the methods are defined in an interface.
>>
> 
> 
>>Instead let's have a Frame as you have.  Let's have things like Errors,
>>Mappings, Accuracy, etc.  Then we assemble quantities as we like and as
>>appropriate out of these things - just as at the moment someone would
>>have to decide which of Basic, Std and CoreQuantities they should
>>subclass from.
>>
>>As an example, I think someone mentioned MagnitudeFrame in the last few
>>days (can't find it now).  It makes sense to me that people can build
>>different Frames, and include these with their values.  We can't do that
>>if the inheritance tree is fixed.
> 
> 
> 	There is no fixed inheritance tree. The proper term is "realization". Each
> 	interface has an established realization relationship between themselves.
> 	*But this is NOT the same as inheritance*. You are not forced into creating
> 	a class hierarchy which mirrors the interface at all. I happen to think its easier
> 	if you do, but hey, thats an *option*. I regret that I lost the argument with the
> 	other editors to change the language surrounding figure 1 to reflect that we
> 	are proscribing "realization" and not "inheritance" relationships, but that is 
> 	what is intended.

Was this argument lost because the other authors think it *is* an 
inheritance tree?!

I appreciate a class inheritance does not *need* to follow an interface 
realisation.  However this interface heirarchy is so property-heavy that 
there's really no other way to do it.  It is this heavy property 
definition that is effectively turning it into a class heirarchy - no 
matter what the intention!

Cheers,

Martin
-- 
Martin Hill
Software Engineer, AstroGrid (ROE)
07901 55 24 66