 |
lua-l archive |
|
|
||
|
On 12/07/15 09:56 AM, Dirk Laurie wrote:
As a "workaround" Lua could call both metamethods. Then everyone would be happy.2015-07-12 14:20 GMT+02:00 Peter Aronoff <telemachus@arpinum.org>: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 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.
-- 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.