Transform point using localToSceneTransform

[Pavel Safrata]

On 28.7.2012 0:06, Richard Bair wrote:
> Vector3D extends Point3D?

No. Vector is not point and point is not vector. As Kevin suggested they 
may have a common parent - Tuple.

Here is the list of things that currently use Point3D as a vector (all 
of them on class Rotate):

X_AXIS, Y_AXIS, Z_AXIS
     we would have to deprecate those and define different ones with 
some uglier names

Rotate(double angle, Point3D axis)
Rotate(double angle, double pivotX, double pivotY, double pivotZ, 
Point3D axis)
     we would have to deprecate those and overload them with another 
ones taking Vector3D

Point3D getAxis()
void setAxis(Point3D value)
ObjectProperty<Point3D> axisProperty()
     this is the biggest issue, even if we wanted to deprecate the 
property I don't know what name could have the new one, also we would 
have to maintain them both, bound to each other, until the old one is 
removed.

This is quite a serious argument against separating point and vector.

Looks like on one side we have ugly Rotate with some deprecated stuff, 
on the other side we have ugly Point with nonsense methods and a bit 
ugly methods in Affine. I still vote for separating because ugly 
property name seems lesser evil than wrong concept and weird method 
names. Anyway, this is a backward compatibility issue and Richard will 
probably have the final word here.

Pavel

>
> On Jul 27, 2012, at 2:19 PM, 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,
>>>