Affine transforms - matrix algebra and matrix categorization "attributes"

[Pavel Safrata]

Hi Jim,
as I've said I don't really want to introduce the matrix type 
classification in this version - maintaining the type would be very 
expensive so I want to avoid it until I hear from users that they want 
it and what exactly do they expect from it.

The is2D() is a special case, because we have a lot of 2D operations 
that throw an exception for a 3D transform, so users should have a way 
to find out whether or not those operations are valid before they use them.

The isIdentity() is not that clearly separated from the other possible 
type classes, but still it is probably the most useful one, because it 
allows you to completely skip any matrix calculations in case it's true. 
It's also fairly easy to track.

I agree with you that the probability of anyone using those as 
properties is pretty low. But please note that calling the getter must 
not necessarily result in the property instantiation. We can write a 
property whose getFoo() always returns the correct value while the 
property is not instantiated until the fooProperty() is called. So the 
only real cost of the property, if it's not used as a property, is one 
null reference and a few if statements.

So my proposal holds, not because I would think that it's useful to 
observe the properties, but because I like the names much better 
(admitting that I regret the loss of is2D):

determinant()
identityProperty(), isIdentity()
twoDimentionalProperty(), isTwoDimensional()

Thanks,
Pavel

On 18.8.2012 0:36, Jim Graham wrote:
> 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...
>
>             ...jim
>