[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: metamethod __lt oddity?
- From: RLake@...
- Date: Fri, 17 Jan 2003 14:09:06 -0500
> 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
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
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
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 ===).