No set methods in the API ? (Was: Re: Relationship between Q and STC - Frames & Mapping
brian.thomas at gsfc.nasa.gov
Tue May 11 08:40:41 PDT 2004
On Tuesday 11 May 2004 06:58 am, Martin Hill wrote:
> > I'd also favor having a boolean method to determine the nature of
> > how the values are generated in a Q also. This is nice because you can't
> > (shouldn't) do "q.setValue(Obj, Location);" method call on a Q that has a
> > mapping behind it. The method thus allows the user to pre-determine
> > whether its OK to make the setValue call rather than having to always
> > catch an error.
> I don't think this is a sufficient check; if values shouldn't be set
> then we shouldn't have a method to do so... If we can map values out
> can we normally expect to reverse them back in? But then I'm not in
> favour of changing values anyway!
But when you explicitly hold values, you definitely will need a way
to "set" the value of a location (!!). One solution is to remove all
set methods from the VO API (they exist only in the implementing
packages), but this will cripple the kinds of applications you can
write which are "universal" to the VO.
I'd be willing to go with not having any "set" methods (something that
Pat once suggested) but only in the _first cut interface_, with the understanding
that these would have to be added back in later on after we got more
experience with usage of Q in the VO.
* 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]
More information about the dm