[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua 5.3 changes to .__eq
- From: Peter Aronoff <telemachus@...>
- Date: Sun, 12 Jul 2015 14:57:51 -0400
Tim Hill <email@example.com> wrote:
> > On Jul 12, 2015, at 7:03 AM, Peter Aronoff <firstname.lastname@example.org> wrote:
> > The reason the difference matters to me is that someone who writes a random or
> > otherwise noncommutative method is (definitely) doing it to themselves. But at
> > least in previous versions of Lua, the language required basic safeguards by
> > requiring that both operands "share the same metamethod".
> > Thanks, Peter
> You can of course simulate this behavior from the metamethod.
True. My concern was as someone writing a test library that offers a method to
tell people whether two arbitrarily chosen items (of whatever type) are the
"same". I was freaked out by the thought of the language allowing == to be
noncommutative. Before deciding how I wanted to handle it in my library, I
wanted to see if the change was intentional and what the logic was.
That said, I understand the argument that it allows for inheritance (which
the previous made hard or perhaps impossible). And as Roberto says if someone
writes __eq methods that create the noncommutative situation, perhaps that's
their fault. My preference would be for the language to disallow it rather
than allow for inheritance (this way), but I can understand that others have
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