Affine transforms - matrix algebra and matrix categorization "attributes"

[Jim Graham]

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