Affine transforms - matrix algebra and matrix categorization "attributes"

[Jim Graham]

Hi Pavel,

I've implemented type() methods on 2 transform classes so far and there 
is no overhead because it is a lazy calculation.  Your comments about 
not wanting to commit to a classification scheme at this point are well 
taken, but don't confuse the costs of a type() method with those other 
reasons and don't confuse the potential existence of a bare type() 
method with the potential of using that word in a naming scheme.

In particular, typeIsIdentity and typeIs2D stand on their own regardless 
of whether there is a type() method so while your explanation of whether 
you want to provide a type() method at this point in time is 
interesting, it does not invalidate those names, does it?

Good point about the cost of having these be properties and there being 
alternate implementation schemes for calculated properties compared to 
the standard get/set properties that we currently see.  A single field 
is much less overhead than the various objects that we might end up 
constructing, yes.

To that end, if we are still interested in having property-friendly 
names then what about "isType2D/3D" and "type2D/3DProperty"?

But, using "Two" in a method name makes me gag a bit... :(

			...jim

On 8/20/2012 2:13 AM, Pavel Safrata wrote:
> 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
>>
>
>