Quantity - how is it used?

[Martin Hill]

On Friday 14 May 2004 12:59 pm, David Berry wrote:
> Is that trailing "ie:" meant to imply that what I later suggest about
> using a Quantity to store a passband seems to contradict what I said
> above? I suppose there are at least two options:

Yes, sorry not very clear...

> 1) Define a separate PassBand model. This would then "use" a CoreQ as a
> "building-brick" to store the transmission values. But there then seems
> little point in having a separate PassBand model if the only thing it
> contains is a single CoreQ.

Sort of, see below...

>
> 2) Just use the CoreQ *directly* as the passand object in some higher
> level model. Say I define a model of a mangelwurzel and I decide my model
> needs to include a passband. The MangleWurzel model has several
> components, each with a type and a name:
>
> MangleWurzel {
>    ...
>    ...
>    CoreQuantity passband;
>    ...
>    ...
> }
>
> So here I *use* a CoreQuantity to store the passband, but there is no
> sub-classing going on. This is what I mean by using Quantity as a building
> block. Of course, if a passband needs anything in addition to the
> definition of its transmission values, then you may need a separate
> PassBand model to aggregate them together. My point is that if your house
> consists of a single brick and nothing else, then you may as well call it
> a brick rather than a house!

Agreed, BUT this is an implementation, not modelling, issue.  If we are 
modelling our SEDs, we should mark, correctly & explicitly, what the object 
is we are modelling and all the objects (eg list of Passband, Flux pairs) 
that go to make it up.  If, when we come to writing our libraries, we find we 
have a ready-made house to use, then fine let's use it.  But our object 
*model* should explicitly mark out what the things are that we expect from 
each object. 

If we treat CoreQuantity, BasicQuantity, StandardQuantity, etc as a set of 
standard library classes to help implementors write code, that's fine.  They 
just don't belong (as types) in the data model, as it makes it difficult to 
model anything but the simplest data.

Cheers

MC

-- 
Martin Hill
Astrogrid/AVO, ROE
Tel: 07901 55 24 66