Affine transforms - matrix algebra and matrix categorization "attributes"
james.graham at oracle.com
Fri Aug 17 15:36:24 PDT 2012
Ah, so the issue isn't so much "I think these should be properties" as
it is "you are using the naming convention for properties".
First, to help with the naming issue, I think "typeIsIdentity", etc. are
perfectly acceptable as "non-property" names. We could potentially pair
them with a "type()" method which would return a bitmask of the various
categorization attributes of the matrix.
As to whether or not these should be properties, here are my thoughts...
I've only ever seen uses of those types of methods in code that was
already actively working on the transform. In other words, it would be
code that was already inside a very large "transformEvent.handle()"
method (or similar). I don't think I've seen any code that simply
doesn't have a single care in the world except when the matrix changes
its nature then suddenly it wakes up and does a bunch of stuff. The
closest I can think of is pipeline validation code which changes
underlying helper objects when the transform changes state. But, the
code that needs to deal with that is *already* having to process the
transform changes themselves and changing the pipeline states is a
byproduct, a tack-on action, of the work it is already doing with the
new transform data. So, again, I'm not entirely convinced that anyone
would ever bind or listen to these properties in a way that wasn't just
as convenient as adding a transform listener.
And the cost of turning these into properties is fairly large. I'll
admit that we seem to be "hooked on properties" in all parts of the API,
but in very many of those cases a property has a fairly large chance of
being dormant and therefore we use defaulting to avoid the creation of
the relatively expensive property objects (though we still pay the price
of a field to hold the null property object reference). In this
transform category case some, if not many, of these attributes will be
somewhat active. isIdentity will have a near 100% chance of requiring
the construction of a property object (that my belief is that a
vanishingly small number of developers who ignored the other mechanisms
would ever use). is2D/3D may have a much higher chance of being
dormant, but I think we should add a few more of these to really be
useful, including "isRotated", "isRectilinear" (related to isRotated,
but allows quadrant rotations), "isScaled", "isTranslateOrIdentity",
"hasPerspective?". The property objects and fields add up...
More information about the openjfx-dev