Heaviness of Q (Was: Re: [QUANTITY] Data Model for Quantity v0.5 - inheritance vs aggregation
Martin @ ROE
mch at roe.ac.uk
Mon May 10 10:25:00 PDT 2004
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.
Software Engineer, AstroGrid (ROE)
07901 55 24 66
More information about the dm