Re: __eq operator behavior

[Guilherme Destefani <guilhermedestefani@...>]

>> I understand that the identity comparison is making the whole
>> operation more optimized in the common case, but I'm not sure that
>> assume everything always compare itself to true is the right
>> thing to do.
>
> Well, if you deny the logical validity of A==A, then Aristotle
> lived in vain.

If A is representing a concrete physical entity, yes, should always be equal.
If A is representing an abstraction, like a number that stands for
something that can't be represented in a precise way, no.
This can happen with other abstractions as well.

>
> What your argument does show, however, is that there is a need for
> a __ne metamethod.  It should not be implemented as the negation of
> __eq, although it may default to that when no __ne is supplied.

Please note that the plain number NaN ~= NaN return true:
---------------------------------------------------------
$ lua -e "nan=0/0; print(nan, '\nnan<=nan', nan<=nan, '\nnan< nan',
nan<nan, '\nnan==nan', nan==nan, '\nnan~=nan', nan~=nan)"
-nan
nan<=nan        false
nan< nan        false
nan==nan        false
nan~=nan        true
---------------------------------------------------------
This is the way that a floating point number should really behave?

Having an __ne operator is not really needed, at least in this
example, if the plain type is behaving in the right way.

So if the __eq was called even when both sides are the same, the table
version of a number and the pure number would behave the same way, for
all comparison operations.

The identity can still be used as a fallback if there is no __eq
operation defined.