lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



> It seems to be as you say, yet the pseudo-code for "__lt" in the manual
> doesn't show this! Something is wrong somewhere.

The code clearly requires the objects to be of the same type for the __lt,
__le, and __eq metamethods. (see lvm.c around line 210). So I suppose the
documentation is wrong -- I would guess that the documentation has not been
updated from Lua 4.

The addition of the __eq method creates some problems; for one thing, it
could make equality tests quite slow, and equality is tested quite a lot.
The resolution, as I understand it, was to only allow overriding __eq on
objects of the same type, which makes things less painful. (I still don't
like the __eq metamethod but I ought to learn to keep things like that to
myself.)

I suppose that it was decided to make __lt and __le consistent with __eq.

Reading the code, I note that __eq does not require the two objects to have
the same metatable or pseudo-type (whatever a pseudotype might mean). So if
any table has a __eq metamethod, that method will be called on any
comparison between that table and any other table. (And similarly for
userdata).

This is awkward because a stray metamethod in a library object could poison
an equality test, leading to the necessity of always using rawequal in
defensive code.

My suggestion would be that the && be changed to || in lines 267 and 274 of
lvm.c so that the metamethod will be called only if *both* objects have
__eq metamethods (then it could always use the __eq metamethod of the first
one). Otherwise I will return to my original suggestion that there be two
different equality operators, one of which is object equality and the other
of which can be overridden (eg. == and ===).

Rici
.