LocalToScene Transformation (related to Affine Transforms)

[Dr. Michael Paus]

Hi,
could you please explain how this will fit into the current class 
hierarchy for transforms?
The general Transform class has all the static methods to create 
specific transforms. If
the Affine class will have all the matrix algebra, then how is this 
supposed to work?
All the specific transformation classes Translate, Rotate, ... are not 
derived
from Affine and thus will not inherit the matrix algebra methods.
Michael


Am 14.05.2012 13:49, schrieb Pavel Safrata:
> Hi Alexander,
>
> On 14.5.2012 11:21, Alexander Kouznetsov wrote:
>> Hi Pavel,
>>
>> On 11.05.2012 13:33, Pavel Safrata wrote:
>>>>
>>>> Can't we just make Affine3D public instead? That way we'll provide 
>>>> matrices calculation layer and all we need is to provide methods to 
>>>> convert Affine3D to Affine and vice versa. Just an idea.
>>>
>>> This sounds like a bad idea to me. From user's point of view, 
>>> Affine3D and Affine would be duplicates except that Affine's members 
>>> are observable. What I think we should do is to port some of the 
>>> Affine3D functionality to the Affine class (which sounds close to 
>>> RT-17942).
>> I don't see a really big difference here. Newly added class 
>> regardless of its name would be "a duplicate" of Affine class. 
>
> I'm not going to add any new class (except of an internal immutable 
> implementation of Transform). The Affine class is already part of 
> public API for a long time, so we should use it and not create any 
> duplicates of it.
>
>> Moreover if you're not going to port all of its methods there would 
>> always be a feature requests to port the rest of them. 
>
> We will consider all the feature requests and implement the reasonable 
> ones. If we end up with something very close to Affine3D, we may then 
> consider switching to the public classes internally.
>
>> On the other hand the Affine class wouldn't be just a class that 
>> members are observable but would be also a class that has no matrix 
>> algebra methods and that is part of Transforms API. Affine3D is 
>> clearly a different layer then.
>
> The Affine class will have the matrix algebra methods. I don't think 
> we should publish any other layer (our proposal tries to avoid that) - 
> that would lead to more confusion and more work with converting 
> matrices between the layers. Everything should work with the existing 
> classes from the user's point of view.
>
> Thanks,
> Pavel
>
>>
>> Best regards,
>> Alexander Kouznetsov
>>
>>


-- 
--------------------------------------------------------------------------------------
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.