Transform point using localToSceneTransform

Jim Graham james.graham at oracle.com
Fri Jul 27 14:19:05 PDT 2012


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,
>


More information about the openjfx-dev mailing list