> > In this case, the order of checking to see what method to call will also > check > for type compatibility. That is, $f < $b checks Foo::__compareTo(), finds > it > doesn't match, and so calls Bar::__compareTo() instead, which does.
I'm not sure if I like this, it's a bit non-deterministic isn't it.. that the comparison function called can be determined by the value being compared? While I'm not disregarding this idea entirely, it's another addition we can add at a later stage. It would be a bit of a juggle internally, to hold on to the type error while we attempt the second call, and if that fails, we throw the type error of the first attempt? > > "However, because magic methods aren't inherited" - Wait, they're not? Are > you certain of that? Because 3v4l.org says they are: > https://3v4l.org/P6Hlq Yeah my bad, that was very poorly written, and I'll update it immediately. What I meant to say was that they aren't inherited from any base object class like `equals` is in Java. So if you just have a base class, magic methods aren't inherited from some language-level base class, so you can use whatever parameter and return types you like. I don't understand Future Scope point 1. It... means we're already covering > those operators. Why is there future scope needed? Python, for example, has the ability to override specific comparison operators, such as > <chasepee...@gmail.com> > __lt__ for <. Point 1 is trying to say that *if* we want to introduce full, specific operator overloading in the future, we would already have the magic methods for == and <=>.
