Re: [eigen] Cumbersome syntax questions/feedback

[Staffan Gimåker <staffan@xxxxxxxxxx>]

On Sun, 2009-08-16 at 22:59 -0400, Benoit Jacob wrote: 
> Hi,
> 
> This is a bit nontrivial: if we start adding row and col, the user
> will start expecting block() too, etc. It would be an unpredictable
> API, if we had row() but not block().

I get your point, and I agree -- the small boon doesn't outweigh the
added maintenance cost.

And you are absolutely right on the expectation part -- it wasn't until
I discovered the operator()(int,int) shortcut that I wanted col() and
row() shortcuts as well.

Is there a reason that operator()(int,int) is treated specially?

> I'm OK to add row, col, block and corner if there's consensus that
> this makes sense to add specifically these methods as opposed to the
> rest of the MatrixBase API. I don't have a strong opinion.

I would be happy with row, col and block, but someone else is always
going to want something else... it's a slippery slope. You have me
convinced that you should NOT add them.

(And, it turns out a lot of those uses of col() and row() I used could
be eliminated by proper use of translation() etc.)

The wish for Transform::inverse() to return a Transform type still
stands, however.

> What's easier to do is make sure that Transform is extensible by a
> EIGEN_TRANSFORM_PLUGIN, in the same way as MatrixBase,
> http://eigen.tuxfamily.org/dox/CustomizingEigen.html
> 
> would that be helpful to you?

I guess that could be useful, and for the sake of consistency having 
that seems reasonable. Personally I prefer to stick with the syntax 
supported upstream, for various reasons.

Thanks for the answers, I appreciate it.

/Staffan

Attachment: signature.asc
Description: This is a digitally signed message part