Re: [eigen] about Transform API

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

On Wednesday 27 August 2008 17:32:52 Gael Guennebaud wrote:
> in my imagination, Scale and Translation would be new types with
> appropriate operator *... Internally they would store a Vector.

OK for this.

In my opinion, Translation and Scaling (please call it Scaling not Scale...) 
should only be helper classes for constructing Transforms. No need for 
Translation::operator*(vector) as that is just vector addition. No need for 
Scaling::operator*(Vector) either. Above all, no need to allow vector 
arithmetic in these classes, i.e. no need for 
Translation::operator+(anything). Thomas: that is the main difference with 
Point, which would have had to have the whole vector arithmetic API.

The fact that (quoting your first mail) "though all products involving two 
different transformation types will generate a Transform" will cause 
inefficiency when making a Transform with all 3 kinds of transformations; but 
in practice I doubt that affects many people because
a) in most cases there is only translation+rotation, no scaling
b) if the user puts scaling last, it gets optimized as a diagonalproduct.

All in all, I think that's a good move and is consistent with what you've 
already done for rotation.

Let's keep the rotate()/scale()/translate() methods because this is what 
OpenGL people expect first. Then let's also keep the pre... methods too.

I wonder about the shear() methods. Any use case? I know Qt has them but 
that's not reason enough :)

Cheers,
Benoit