Transform point using localToSceneTransform

[Kevin Rushforth]

I haven't followed this discussion as closely as I might have done.

I'm leery of having separate Point and Vector classes without a common 
superclass. As part of Java3D we developed javax.vecmath, which has the 
following class hierarchy (for various dimensions and precisions):

Tuple
   +-------Point
   |
   +-------Vector

Many of the methods were in the Tuple base class; those methods that 
just don't care whether something is a point or a vector, even some that 
may not make sense for point (like add). For those places that actually 
matter, you put the functions in the subclass.

The main thing that is important from an functional point of view -- and 
many real world apps needed this -- is the ability to construct / set a 
Point from an arbitrary Tuple (ditto for constructing / setting a 
Vector) without reading out all of the values manually (e.g., we had 
"Point3d.set(Tuple3d)" and "new Vector3d(Tuple3d)")

Easy conversion between the Point and vector classes is important even 
if you don't have a common base class. Otherwise developers have to do a 
bunch of manual copying (or silly things like subtracting a 0 vector 
from a vector to convert it to a point).

Personally, I wouldn't mind having a single class that was less strongly 
typed (like Jim was originally suggesting), but I can see advantages of 
having separate more strongly-typed classes as long as they "play nice" 
together.

-- Kevin


Jim Graham wrote:
> This is starting to make sense to me as I see more examples of how the 
> 2 are used.  I'm definitely seeing the value of separate types for 
> making code readable and for encouraging proper math.  It's like 
> making our geometry code "strongly typed" - in the Java spirit...
>
>             ...jim
>
> On 7/26/2012 7:35 AM, Pedro Duque Vieira wrote:
>> Hi again,
>>
>>
>>> Hi Kirill,
>>> On 26.7.2012 10:10, Kirill.Prazdnikov wrote:
>>>> On 26.07.2012 10:20, Pavel Safrata wrote:
>>>>> Exactly, I think the point is that 'point' is not 'vector' regardless
>>>>> of what workarounds we introduce in method naming and documentation.
>>>>> Those methods would look really weird on Point.
>>>>
>>>> Both are from the same R3 space, right ?
>>> Right.
>>>>
>>>> And we can add them together :
>>>>   Vector speed, position;
>>>>    position += time * speed;
>>>>
>>>> I vote for Jim`s approach.
>>> Does it make sense to add two points? I think it doesn't. So if we have
>>> Point and Vector, we need something like Point.add(Vector) or
>>> Point.shift(Vector). In Jim's approach we need Point.add(Point) with
>>> documentation stating that one of the points represents a point and the
>>> other one represents a vector. So what is the advantage?
>>>>
>>>
>>
>> Exactly. Adding two points doesn't make sense.
>>
>>
>>
>>>> If a transform is { M3x3 + Translate }, them
>>>>   - transformPoint (normal transform) would be { P*M3x3 + Translate }
>>>>   - transformVector (delta transform) would be { P*M3x3 }
>>> We already know that it is possible to represent both things by one
>>> class and move the distinction to method names and documentation. But
>>> please explain what is the advantage of it (except the obvious one of
>>> having lower class count).
>>> Thanks,
>>> Pavel
>>>>
>>>> -Kirill
>>
>>
>> If you go this way with point you could go this way with a lot of other
>> framework classes: say you could use Point2d to represent a 
>> Dimension2d, a
>> BoundingBox to represent a Rectangle2D or Insets, etc.
>> I personally don't really think this is a good approach.
>>
>> Thanks, best regards,
>>