Proposal to split out the "members" from coreQ (Was: Re: Philosophy of basic Q)

[Brian Thomas]

On Tuesday 11 May 2004 12:40 pm, Patrick Dowler wrote:
> On Tuesday 11 May 2004 08:51, Martin @ ROE wrote:
> > Brian Thomas wrote:
> > > 	Well, my concept of BasicQ (and I don't think I'm alone on this)
> > > 	is that it was for _holding a single value_, not to make
> >
> > something
> >
> > > 	"really simple".
> >
> > In that case can we change the name to SingleQuantity?  There's not
> > enough distinction between 'Core' and 'Basic'!
>
> The correct term for it is "atomic" which is what Gerard and I used in the
> much maligned and misunderstood "unified domain model for astronomy" :-)
> But I got voted down on having AtomicQuantity in the current doc in favour
> of "more friendly and less CS-ey" terminology.

	Why is "atomic" more correct than "single"?!? 

>
> Also, no one seems to have noticed that CoreQ allows for either arrays or
> components (parent-child structure) BUT NOT BOTH at the same time!!!

	I have noticed. In our original proposal this was called a "quantityset".
	In the implementation I am working on, I have a QuantitySet class which
	only takes members, and a "ListQuantity" class that only takes values.

	I agree that it would be better to have separate interfaces. The only issue
	this raises is that you cannot have an axis where the values are "quantities"
	rather than strings or numbers. I'm OK with this as its not a likely use-case,
	and the change can always be added later if its really that critical.

>
> I also argued unsuccessfully that these two kinds of things should be
> separate, which I why (way back last fall after adass) I proposed
> AtomicQuantity, ArrayQuantity, and CompositeQuantity as 3 sibling types
> (the domain model didn't have ArrayQuantity). But that eventually got shot
> down in favour of cramming several distinct concepts together....

	Ugh. You should have spoke up while I was trying to argue having a QuantitySet
	interface then. But that is past history...lets try to be constructive moving
	forward, eh??

	Look,  we agree on the following :

	We *do* need a quantity which is a composite of other quantities.

	We *do* need a quantity which is a list of values.

	And I would add (along with others) that :

	We *do* need a quantity which can hold matrices of values (which I view
	the list as a special case of).

	All that is needed then is to create a QuantitySet/CompositeQuantity interface
	by peeling off the needed methods from coreQ.

	I don't believe it is too late to revise this to separate out the "member" stuff
	from Core/Standard Q and put it in a separate interface. What do other people
	think?


	=b.t.


-- 

  * 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]