[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua 5.3 changes to .__eq
- From: Andrew Starks <andrew.starks@...>
- Date: Sun, 12 Jul 2015 09:00:37 -0500
On Sunday, July 12, 2015, Daurnimator <quae@daurnimator.com> wrote:
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
I think that this change was motivated in part by this thread:
