Affine transforms - matrix algebra
pavel.safrata at oracle.com
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.
> 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.
More information about the openjfx-dev