Yes, this issue has been bugging people on the list (including me) for at least a couple of years. There has been a fair amount of debate --check the archives-- although I never read anything to convince me of the soundness of Sun's approach. Whenever I write my own function, its parameter list uses Tuples so that I can pass it Points or Vectors -- whatever is convenient at the time. I wish Sun had done this also. The only gotcha that I am aware of is that Transform3Ds transform Vectors differently that Points.
Raffi -----Original Message----- From: Sean Sylvis [mailto:[EMAIL PROTECTED]] Sent: Friday, March 01, 2002 2:29 PM To: [EMAIL PROTECTED] Subject: [JAVA3D] vecmath library interface I was just wondering if there were any plans to *improve* the vector library interface. When first working with the library, I often found myself having to convert between Points and Vectors in order to perform calculations. For instance, I would be using Point3d objects to perform calculations on object locations in my virtual universe. Then, I would want to use the result of my calculations as the basis of a translation. To set the translation component of a Transform3D object though requires a Vector object. This is just one example, but I felt like I was doing this quite often. In the end, we (my company) decidedly to implement my own linear algebra library with a more defined interface hierarchy. At the top of the interface is a Tuple object with methods that operate on tuples without having to know about the number of elements. Under this are the Point and Vector interfaces, which likewise specify methods that operate on points and vectors without having to know about the number of elements. Then, a Real and Integer interface version of each of these is defined, inheriting from the appropriate super-interfaces, and adding methods that use type information -- i.e. RealTuple, IntegerPoint, etc. Under this level, are 2d, 3d, 4d, and Nd interface definitions, where element accessors (setters/getters) are added -- i.e. RealTuple*d, IntegerPoint*d, etc. Finally, concrete classes are defined, implementing the type-specific methods, but allowing the most general interface possible as a parameter type -- i.e. defining the method, public double distance(RealTuple3d), in the DoublePoint3d class and, public float distance(RealTuple3d), in the FloatPoint3d class. While this may seem unwieldy, given the explosion in the number of implemented classes, and unnecessary, given the availability of the vecmath library, we found the lack of any sort of interface hierarchy for the vecmath library extremely limiting. With our implementation (which we also extended to matrices), the inheritance features of the object-oriented Java language were utilized, while still allowing for compiler optimization on each type at the implementation level. Anyway, sorry for long-winded email. Just my thoughts on the subject, since much of my time went into the re-implementation of a linear algebra library. Sean ==========================================================================To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
