[QUANTITY] Why quantities sometimes have errors

[Brian Thomas]

On Monday 17 November 2003 02:25 pm, Martin Hill wrote:
> OK happy that using simple subclassing is inappropriate for the vast
> number of different quantities that there are (and apologies for not
> catching up with the backlog to have known this).
>
> But it does sound as if you're going for an all-inclusive concept (?) -
> for example, if we're looking at quantities with or without units,
> surely we must consider quantites with or without errors?  And we should
> not be making a placeholder for these subcomponents if these subcompents
> are not always required... which is the point I was trying to make, even
> if my example seems to have diverted the issue.  I'm really not happy
> (from an OO design point of view) with including things that, by
> default, are not used.  It implies the relationships/concepts have not
> been though through properly.

	My anwser here is that *no*, I dont think it is sloppy to require information that clarifies
	whether or not something has errors, even if you know you never want to use different
	errors. Certainly, if you were designing classes for your own internal consumption,
	then there is no need to be "formal", you would have your own internal convention. 

	But when software is to be shared by large groups (like the VO) it really pays to be 
	explicit about the meta-data, rather than having an assumption. Again, I accept that
	people will want to design classes that are "errorless". BUT, as there are different kinds
	of "errorless" ('exactValue' and 'noDefinedError' come to mind) AND it makes a difference 
	in the semantic meaning of the quantity, then we need to make a clear, explicit, 
	default for errors.

	Again, if you require that the new class meet an interface, then you can just have your
	new class return a "default" error and be done with it. We are talking about a grand
	total of *maybe* 5 minutes of programmer time for the sake of clarity to make the quantity
	valuable for us by all.

>
> Which takes me back to my original question on this: what is a
> [QUANTITY] for?  It sounds like we have lots of different quantities
> that don't really have anything in common.  Not even the term 'Value' in
> the diagram, which if it was typed would end up being entirely different
> between qantities ??  In which case shouldn't we be looking at these
> different things seperately (eg Measurement) which might have common
> components (eg Error) rather than trying to make an all-encompasing one?

	Value is an abstract class/interface that we would need to define. I would assume
	this to mean, at minimum, the Java-like "Number" class. I would also include 
	"String", but Im sure others would disagree.

	-b.t.


-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128