Re: Lua 5.3 changes to .__eq

[Daurnimator <quae@...>]

On 12 July 2015 at 23:35, Peter Aronoff <telemachus@arpinum.org> wrote:
> 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?

I think they were saying that you could write a metmethod that is not commutive:

mt = {}
mt.__eq = function(a,b)
    return a.a == b.b
end

foo = setmetatable({a=1; b=2}, mt)
bar = setmetatable({a=2; b=3}, mt)
print(foo == bar, bar == foo)


Of course, nothing ever stops you from just having random results either. e.g.

mt.__eq = function(a,b)
    return math.random(0,1) == 1
end