> . . .
> still, the method itself seems to have to "hard code" it's
> reference DataTupleType, and so i dont see what's the point
> of passing in the reference DataTupleType to the
> initializer. HSVCoordinateSystem, for example, never refers
> to its field "Reference". nor does CoordinateSystem.
Its a way to organize the connection:
RealTupleType -> CoordinateSystem -> Reference RealTupleType
The direction of these references is appropriate for the
way this connection is accessed.
> I see that HSVDisplay defines a realTupleType for its
> reference coordinateSystem. What are the implications on
> that vs using a DisplayRGBTuple ?
DisplayRGBTuple is an instance of DisplayTupleType, which
extends RealTupleType, so DisplayRGBTuple is an instance of
RealTupleType.
> the down side of letting the calling routine pass in the
> reference is that they might pass one in that doesnt match
> whats actually used, not to mention the extra trouble of
> constructing it. Since apparently this is used only by
> objects calling getReference(), it could be a source of
> problems not forseen by the person who writes the class or
> the person who constructs it.
Quite true, a concern also raised by Tom Rink. However,
VisAD is intended as the foundation of many libraries and
APIs built on top of it, and at the lowest level I prefer
to chose flexibility over safety. I already have two examples
of applications where I need this particular flexibility.
CoordinateSystem constructors will be invoked mostly by Data
Form adapters rather than by applications. In other words,
applications will be protected from this flexibility by
intermediate APIs. Furthermore, if you are very concerned
about this, you can define CoordinateSystem extensions that
do hard-code their Reference RealTupleType, rather than
defining it as a constructor argument.
> the reason that this is not completely a trivial point is
> that the seperation of the CoordinateSystem from its
> reference adds a level of possibly unnecessary complexity
> that, for example, that makes paragraph 3.4 in the
> developers guide hard to understand.
As I said, I like flexibility in foundation APIs. You'll
have to be more specific about wording in Section 3.4.
> As an aside, I want to acknowlege how hard it can be to hear
> someone criticize designs you've thought a lot about, or
> even ones you threw together in the haste to get something
> working. I appreciate your willingness to consider my
> reactions as I try to understand the visAD design.
I am sure you mean well, but I'd rather you focus your
comments on the system rather than me.
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
whibbard@xxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html
