Re: Lua 5.3 changes to .__eq

[Peter Aronoff <telemachus@...>]

Tim Hill <drtimhill@gmail.com> wrote:
> > On Jul 12, 2015, at 7:03 AM, Peter Aronoff <telemachus@arpinum.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".[1]
> > 
> > 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
other priorities.

Thanks, Peter
-- 
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