Affine transforms - matrix algebra and matrix categorization "attributes"

[Pavel Safrata]

Hi Jim,
good idea! I like the type2DProperty() and isType2D() much better.
Thanks,
Pavel

On 20.8.2012 22:25, Jim Graham wrote:
> 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
>>>
>>
>>