[QUANTITY] Data Model for Quantity v0.5 - inheritance vs aggregation

[David Berry]

Martin,

> Given that Frame -> BasicQuantity -> StdQuantity all define the contents
> of a Quantity, and very little about behaviour, we actually have classes
> with all the inheritance problems (and benefits) associated with these.

There was quite a bit of discussion between the authors as to whether a
Quantity "is a" Frame or "has a" Frame. All views welcome!


> Instead let's have a Frame as you have.  Let's have things like Errors,
> Mappings, Accuracy, etc.  Then we assemble quantities as we like and as
> appropriate out of these things - just as at the moment someone would
> have to decide which of Basic, Std and CoreQuantities they should
> subclass from.

There's a lot of sense in this. What would presumably happen is that
certain patterns of usage would crop up over and over again, and could
therefore justify being supported as a separate class. The current
inheritance hierarchy between StdQ, BasicQ and CoreQ is partly aimed at
allowing "everything to be a Quantity". That is, if a Q holds a 2-D image,
then the current system is designed to ensure that the information
describing the (RA,Dec) calibration of the image are also stored as
Quantities within the enclosing Quantity. As to whether this is a
desirable thing is another mattter...


> As an example, I think someone mentioned MagnitudeFrame in the last few
> days (can't find it now).  It makes sense to me that people can build
> different Frames, and include these with their values.  We can't do that
> if the inheritance tree is fixed.

Indeed. I would be in favour of BasicQ aggregating a Frame rather than
inheriting from Frame. Actually inheritance from Frame could be retained
though, even if we aggregate a Frame within BasicQ. It would just mean
adding a getFrame() method to BasicQ, and adding the understanding that
when a Frame method is invoked on a BasicQ, the implementation will just
forward the method to the aggregated Frame. But maybe someone could remind
me *why* BasicQ inherits from Frame rather than containing a Frame?

> 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...

Not sure what you mean by "be part of" - Mappings are defined totally
separately from Q, but are aggregated as components within the Q model.

If a 2D image Q wants to express the relationship between pixel coords and
(RA,Dec) (for instance), then the Q will need to contain a Mapping
describing how to transform the pixel coords, and will also need to
contain a Frame saying what this transformation gives you (in this case,
the Frame will identify the Mapping outputs as (RA,Dec)). If the user
wants to use (l,b) coords instead of (RA,Dec) coords, then the CoreQ
which contains the Frame and Mapping will need to be know how to convert
"what we have got" (RA,Dec) into "what we want" (l,b). This is do-able.

David