>
> We can just define that == calls __equals on the left. That's, for
> example, what Python does. This would produce a weird consequence of $a
> == $b and $b == $a not being the same, but that's what you get for
> overloading operators. That's why overloading operators is not always
> the best idea, because of disconnect between perceived semantics (math
> equality operator, which is symmetric, reflexive and transitive) and
> actual semantic (which is not guaranteed to have any of the math
> equality properties).
Invoking on the left would break the symmetry of $a == 1 and 1 == $a. The
current implementation considers both operands but LHS takes precedence. I
think that this is the best approach so that the order of the operands
should not affect the result. Of course, when comparing two objects, that
would only work if their definition of equality is consistent. Honestly,
unless it's an implementation error on the user's part, I don't see this
being a real problem that would cause confusion or require workarounds.
I know this is talked about in detail in the RFC but it's worth repeating
here: the intention of this RFC is to preserve the semantics of the
operators. Operator overloading is an unavoidable side-effect of overriding
the behaviour that the operators are semantically attached to.
In any case, "the same class" would be too restrictive, as there's
> inheritance, so we should support LSP. But then again, if $a and $b are
> in different places on inheritance hierarchy, we can can non-symmetric
> operator. This is kinda deep problem that is not really working well in
> most Java code, for example. See:
> https://www.artima.com/pins1ed/object-equality.html (for reference,
> Martin Odersky is the guy who did Java generics, and designed Scala, so
> he knows a quite bit about OO things :)
That was a great read. A lot of these problems seem to stem from method
overloading and hashCode implementation - neither of which are problems
that we need to consider here. The bottom line is that there will be the
potential for asymmetry, I don't think we can avoid that without a lot of
restriction or double-comparison.
Somewhat related, and in response to Levi's mention of it in this thread,
I've added a frequently asked question regarding Python 3's removal of
__cmp__. Please see:
https://wiki.php.net/rfc/object-comparison#why_did_python_3_remove_cmp_in_favour_of_rich_comparisons
...
