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

[Brian Thomas]

	Ugh. I gotta stop replying to all this dm stuff and do some work, but, OK,
	one more for today..


On Monday 10 May 2004 01:25 pm, Martin @ ROE wrote:
> 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?

	Quantities DON'T carry around all the mappings. They merely have 
	a set of methods to allow access to the "Mapping" interface. Personally,
	I'd limit the interdependence in the interfaces to a constructor method, 
	and informational operation, e.g.

	public interface StandardQuantity {

		....

		/** construct a standardQ that generates values from mapping */
		public StandardQuantity(Mapping mappedValues);
	
		// tells if the values are generated by mapping (true) or held explicitly (false)
		public boolean hasMappedValues();

		....

	}

	And thats it. Whats the problem with that?!?

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


	I agree. I'd like the BQ to allow for mapped values, but a bare majority of
	the other editors voted it down.

> And I think the Quantity user is the right place to keep the Mappings
> the user might want.

	Hmm. Don't understand. 

	Cheers,


	=b.t.

>
> Cheers,
>
> MC

-- 

  * Dr. Brian Thomas 

  * Dept of Astronomy/University of Maryland-College Park 
  * Code 630.1/Goddard Space Flight Center-NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128 [GSFC]
           (301) 405-2312 [UMD]