LocalToScene Transformation (related to Affine Transforms)
james.graham at oracle.com
Fri May 11 15:55:44 PDT 2012
Thanks for clarifying the mutability issues for properties for me. I
think I get the proposals better as well.
On 5/11/2012 1:14 AM, Pavel Safrata wrote:
> On 11.5.2012 8:25, Jim Graham wrote:
>>> So we propose yet another approach. In the base Transform class,
>>> introduce getters for all the elements of the transformation matrix (not
>>> observable, just getters). Each transformation would be able to return
>>> the values according to its current state. Our property would then be of
>>> type Transform, allowing only for getting the matrix values. This would
>>> make the property observable as a whole (creating a new instance each
>>> time), unmodifiable, and would leave us with a nicely open way to
>>> introduce the methods for matrix operations on the Transform class, most
>>> of them probably returning the Affine instance as a result, and the
>>> Affine class could then have a bunch of methods to be modified in place.
>> How important is immutability in the values of properties? Because you
>> say that the Transform value here would be "unmodifiable", but it
>> would be unmodifiable only in terms of its declared type and if you
>> choose to return an Affine then it can be cast and modified which
>> would mean we don't really care about the mutability of property
> I think I never told I would choose to return Affine. Just the opposite,
> I would probably boost the performance by returning something that
> doesn't have twelve property objects that take ages to even construct.
I see now that I misread "returning the Affine instance" as meaning that
you would choose the Affine class as the implementation of Transform to
return from the property. But, I see now that you were referring to
returning it as the "answer" from the manipulation methods on Transform,
though I think you could just declare their return values as Transform
as well and then just have it coincidentally be an Affine in most cases.
So, what you are proposing here is:
- Transform would add methods to get the various elements of a matrix
(but not set). (And it might also add other "informative" getters like
- We'd create an internal immutable transform subclass that we'd use as
the values of this property.
- In the future we might add manipulation methods to Transform, but they
would all return the result as a Transform or Affine and leave the
original object unmodified. (Technically, subclasses could use
covariant return values to further narrow the type of the answer -
Transform.rotate() would have to return a Transform, but Rotate.rotate()
could return a Rotate and Rotate.scale() could admit to returning an
- In the future we might also add manipulation methods to Affine that
manipulate it in place.
- Neither of those last two would affect the immutability of Transform
being used as the value of this property.
I like this idea...
More information about the openjfx-dev