[QUANTITY] Why quantities sometimes have errors

[Martin Hill]

If at the design stage we can see a set of situations where a component 
of a class will be unused, we should remove that component and place it 
in a subclass.  It seems we agree there are places where this is so (for 
example, in constructing a cone search?)

So it makes sense to me (as a developer) that you have a quantity 
without error, and a subclass that includes error.  Errors too will 
require a heavy duty definition and no doubt a lot of discussion on this 
forum...

I do understand that we need to encourage people to include errors. 
That however must be done at the stage where we define our particular 
data models where errors are important.  By having with and without 
error classes, we can force errors to be included - by including the 
[QUANTITY_WITHERR] class.   If we use instead our generic [QUANTITY] 
class that has an optional error, we do not enforce anything - people 
can (and will) just set that error to null.

Cheers,

Martin

DIDELON Pierre wrote:
>>From brian.thomas at gsfc.nasa.gov Mon Nov 17 18:31:06 2003
>>From: Brian Thomas <brian.thomas at gsfc.nasa.gov>
>>To: DIDELON Pierre <dide at discovery.saclay.cea.fr>
>>Subject: Re: [QUANTITY] Why quantities always have errors (Was: Re: [QUANTIT] Use-cases, role in larger scheme)
>>Date: Mon, 17 Nov 2003 12:30:22 -0500
>>User-Agent: KMail/1.5
>>Cc: dm at ivoa.net
>>MIME-Version: 1.0
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: inline
>>
>>On Monday 17 November 2003 12:14 pm, DIDELON Pierre wrote:
>>
>>>If you have to pass a parameter to an application, to specify some input
>>>value, you may need to transmit a value (without error), it can even be a
>>>flag. This is a very immediat example, and we can not rule out in VO (IMO),
>>>the usage of numbers without error, once for all,
>>>even if today it seems more natural to you,
>>>SOME PEOPLE outside here want to use numbers without errors,
>>>and ask for that possibility several times on the list (and off the list),
>>>and it would certainly be appropriate in some cases.
>>
>>	This can be resolved by simply choosing a sensible default meaning
>>	for the error == NULL.
>>
>>	I suggest that if an error isnt present (e.g. returns null), then its meaning 
>>	is "error, unknown". If you want to create a 'constant' then you would get
>>	something else, e.g. quantity->getError() returns "ExactNoError" class.
>>
>>	And its a pretty trivial detail of construction of the class, I think in terms
>>	of implementation. Say you want to create 2 classes that embody "hardwired"
>>	errors (so implementer doesnt need to thinik about the errors), such as 
>>	"constant" and "parameter",  then, assuming a quantity interface, we have:
>>
>>	class Constant implements Quantity {
>>
>>	ErrorType getError () {
>>		return new ErrorExact();
>>	}
>>
>>	}
>>
>>	and for your "parameter":
>>
>>	class Parameter implements Quantity {
>>
>>	ErrorType getError() {
>>		return new UnknownError();
>>	}
>>
>>	}
>>
>>	Regards,
>>
>>		=b.t.
>>
>>
>>-- 
>>
>>  * Dr. Brian Thomas 
>>
>>  * Code 630.1 
>>  * Goddard Space Flight Center NASA
>>
>>  *   fax: (301) 286-1775
>>  * phone: (301) 286-6128
>>
>>
>>
> 
> WHY?
> why trying to complicate the smallest and simplest things?
> Why not admitting the co-existing of 2 classes, one using the other?
> Why not let the one who want to play without error to do so?
> Pierre
> PS: last mail of today... I'm going home.
> 

-- 
Software Engineer
AstroGrid @ ROE
Tel: +44 7901 55 24 66
www.astrogrid.org