# Transform point using localToSceneTransform

Pedro Duque Vieira pedro.duquevieira at gmail.com
Thu Jul 26 07:35:50 PDT 2012

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,

--
Pedro Duque Vieira