[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **Re: Lua 5.3 changes to .__eq**
**From**: Peter Aronoff <telemachus@...>
**Date**: Sun, 12 Jul 2015 09:35:45 -0400

Coda Highland <chighland@gmail.com> wrote:
> On Sun, Jul 12, 2015 at 5:20 AM, Peter Aronoff <telemachus@arpinum.org> wrote:
> > Hi,
> >
> > I'm a little confused abut the changes to .__eq in Lua 5.3. Now that Lua will
> > call the first .__eq found if *either* of the two operands to == has a defined
> > .__eq method, some odd results seem to follow. In particular, == is now order
> > dependent. x == y and y == x can return different results. Is this really
> > desirable?
>
> Consider that the operation wasn't commutative before, either, in the
> case where __eq was defined on one and not the other.
I thought that under the previous rules, == was commutative, insofar as if only
one of the two items defined __eq, then x == y and y == x would *both* return
false. At least that's what I see in Lua 5.2:
$ lua-5.2
> x, y = {4}, {5}
> mt = {}
> mt.__eq = function () return true end
> setmetatable(x, mt)
> = x == y
false
> = y == x
false
> setmetatable(y, mt)
> = x == y
true
> = y == x
true
Or have I misunderstood what you meant?
Thanks, Peter
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System