Affine transforms - matrix algebra

Pavel Safrata pavel.safrata at
Thu Jul 12 02:28:15 PDT 2012

On 11.7.2012 18:31, Pavel Safrata wrote:
> On 11.7.2012 17:39, Martin Desruisseaux wrote:
>> Le 11/07/12 16:57, Pavel Safrata a écrit :
>>> If we are going this way, shouldn't we do also this?
>>> * Rename 'concatenate' as 'prepend'
>>> * Rename 'preConcatenate' as 'append'
>> Yes, I think it would bring more uniformity in the method naming.
>>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-)
>> I missed that method... What would its function? Or are we are 
>> talking about something like a 'getTransformCoefficients()' method?
> This method is similar to concatenate (prepend) except that it is 
> defined on parent Transform class and returns the result in a new 
> Transform instance (allows for multiplicating arbitrary - possibly 
> immutable - transfroms).

What about something like getCompound(Transform)? Probably switching its 
meaning so that a.getCompound(b) returns equivalent transform to 

>>>> I don't have experience in this area. But naively, it seems to we 
>>>> that it would be better to be notified only after the full matrix 
>>>> has been updated...
>>> Yes, I would also pick this option. It's just that it would mean 
>>> writing much more complicated (and a bit less effective) code so the 
>>> question is whether or not you think it is important.
>> I don't have a use case where I would like to listen to individual 
>> coefficient changes. It seems to me that I would rather listen to 
>> whatever property contains the Transform object as a whole. 
>> Consequently, I don't think that the atomicity of Affine operations 
>> would have much incidence (assuming that there is some way - other 
>> than listening to individual coefficients - to be informed that the 
>> matrix as a whole has changed).
> Unfortunately I don't think there is a way to listen for changes on an 
> object other than listening on all its properties. In my opinion this 
> is quite a big issue and it's been bothering me for some time already. 
> I've heard that some utilities are planned for that but still I want 
> to file a feature request for some better mechanism, hopefully this 
> email gives me the impulse to finally do it.

I've filed


> Anyway, I should probably not give up on the (quite obviously) better 
> API just because of implementation complexity. Will try to make the 
> changes atomic.
> Thanks,
> Pavel
>>     Martin

More information about the openjfx-dev mailing list