No set methods in the API ? (Was: Re: Relationship between Q and STC - Frames & Mapping

[Brian Thomas]

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.


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