lua-users home
lua-l archive

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

On 12/07/15 09:56 AM, Dirk Laurie wrote:
2015-07-12 14:20 GMT+02:00 Peter Aronoff <>:

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

Consider the code below and the results it would yield for Lua 5.3 versus for
earlier versions of Lua:

     foo, bar = {4}, {4}
     mt1, mt2 = {}, {}
     happy = function () return true end
     sad = function () return false end
     mt1.__eq = happy
     mt2.__eq = sad

     print(foo == bar, bar == foo) -- false, false for all versions

     setmetatable(foo, mt1)
     print(foo == bar, bar == foo) -- false, false or true, true?

     setmetatable(bar, mt2)
     print(foo == bar, bar == foo) -- false, false or true, false?
The old behaviour required metamethods to be identical.

This disqualifies inheritance situations. I.e. suppose there
is a constructor A=myclass(B) which basically packs the
metatable of A and falls back to B otherwise. Now A==B is
quite a reasonable thing to test for, but it would always be
false under the old behaviour. The asymmetry is the price
you pay for the extra flexibility.

I agree that it is a little counterintuitive and possibly confusing
to newbies, but IMHO programmers who exploit metamethods
declare themselves to be de facto non-newbies.

As a "workaround" Lua could call both metamethods. Then everyone would be happy.

Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.