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

[Martin @ ROE]

Brian Thomas wrote:

> 
> 
> Martin wrote:
>>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.  And if the Quantity user has to set the right 
Mapping before getting the values it wants, then we hit the mutability 
problem again.  What happens when one 'view' on an instance wants to use 
one Mapping, and another 'view' wants to use a different one?

I think Mappings should deal with Frames and values, being able to 
produce values for other Frames. Presumably there is no reason why we 
can't apply a Mapping to a BasicQuantity to get another BasicQuantity? 
And I think the Quantity user is the right place to keep the Mappings 
the user might want.

Cheers,

MC

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