Re: [openvrml-develop] Re: VrmlMatrix

[Braden M. <br...@en...>]

On Thu, 2001-10-11 at 14:34, S.K.Bose wrote:
> 
> 
> On 10 Oct 2001, Braden McDaniel wrote:
> 
> > 
> > In general, class interfaces should not provide multiple means of doing
> > the exact same thing. The methods MMleft() and MMright() provide the
> > necessary functionality; and I prefer this approach as it is consistent
> > with the ECMAScript VrmlMatrix definition. 
> 
> Technically I am not convinced after all it is C++ lib.
> 
> In VrmlSFVec3f we have the methods getX(), getY() and getZ() but still we
> have the operator [] Why? Because this is more convenient and conventional
> notation. We are more *familiar* and *comfortable* with this notation from
> our school days through textbook.

Those methods do access the same values, but the different means of
access are important. operator[] lets me get the color using an integer
argument, which is necessary when iterating. But getX() and the like are
more expressive when the context applies only to a single element of the
vector. It's true that we could live with *only* operator[] for access
(or some similar method that takes an index argument), but I think that
getX(), etc., provide a valuable distinction where that distinction is
important. In code that cares only about the z-component, I think
"v.getZ()" is more obvious than "v[2]". I don't think that operator* for
multiplication of VrmlMatrix adds clarity in the same way.

For someone who hasn't seen the header to VrmlMatrix, I think the
function of "m.multRight(n)" would be completely clear. A reader can
look at "m * n" and be *pretty* sure about what it does, but not
completely (IMO). Consider that many C++ programmers are appropriately
wary when they see an overloaded operator in an unfamiliar context
(familiar contexts for overloaded operators would be STL iterators,
smart pointers, iostreams, ...).

> >         * Rather than have the static method identity(), why not just
> >           have the default constructor create an identity matrix?
> > 
> Probably you are right. I was more concerned about performance.

While operations on matrices will be performance critical, I don't think
matrix creation is likely to be a bottleneck.

***

I was just reading your ChangeLog comments, and you say

        * A New Class VrmlMatrix is implemented. Here the format
          is same as OpenGL standard. So this matrix can be used
          transparently as OpenGL matrix.

OpenGL matrices are column-major, whereas VrmlMatrix is row-major. I'd
like to keep VrmlMatrix row-major, but that difference should be kept in
mind when feeding them to OpenGL.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>