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

[David Berry]

Martin,

> >>Thinking about it more, Mappings should definitely not be part of the
> >>Quantity; Mappings (if I have them right) define how to convert values
> >>between one Frame and another, and this depends upon what the Quantity's
> >>user wants, not upon what the Quantity has.  The Frame should define
> >>enough about the source & target values to know which Mapping to use...
> >
> >
> > Mappings currently *don't* have a relationship to Q. This is because mappings
> > work on *values* and not whole Quantities. In the future, should there be a need,
> > we may wish to create a "QuantityMapping" interface, but this is NOT in the works.
>
> I appreciate that was the original intent - that Quantity acts somewhat
> like a Mapping arbitrator, so that you ask Quantity for a value in a
> certain way and it does the right Mapping.  However it's not right that
> Quantity should try to carry around all the right Mappings for all the
> possible requests.

Ah, now I see what you mean. Indeed there is no need for a Q to carry
around Mappings from pixel->(RA,Dec) *and* from pixel->(l,b) *and*
from pixel to ecliptic coords, etc. Only one of these need be included
in the Q itself because any Q implementation worth anything will know
how to convert between (RA,Dec), (l,b), ecliptic, etc. But you do though
need to have *one* of these Mappings available in the Q, otherwise you
do not have anywhere to begin.

David

----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project		 |	Centre for Astrophysics
(http://www.starlink.ac.uk/)	 |	University of Central Lancashire
Rutherford Appleton Laboratory	 |	PRESTON
DIDCOT				 |	United Kingdom
United Kingdom			 |	PR1 2HE
OX11 0QX                                Tel. 01772 893733
                                             01257 273192