On Thursday, June 28, 2018 9:47:56 PM CDT Rudolf Theunissen wrote: > > 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?
Thinking on this more, I think we have to do it in some fashion. The current
rules in the RFC say:
* Check if $a has a __compareTo() method. If so, use it. Else:
* Check if $b has a __compareTo() method. If so, use it. Else:
* Default behavior.
However, that ignores the case where $a has a __compareTo() that is not type-
compatible with $b. In that case, the current rules in the RFC would imply
"call $a with a type mismatch, get a TypeError", regardless of whether
$b::__compareTo() would work."
I would suggest the better logic be:
if (either $a or $b have a __compareTo()) {
if ($a->__compareTo() exists and is type compatible with $b) {
use $a->:__compareTo()
}
else if ($b->__compareTo() exists and is type compatible with $a) {
use $b->:__compareTo()
}
else {
throw a new InvalidComparisonError (new type, extends TypeError)
}
}
else {
Default behavior
}
That way we don't need to track A's or B's type error, we just say "if either
of these objects is opting in, do whatever we can. If not, it means we don't
want default behavior." Obviously an untyped compareTo() method is always
type compatible with anything, so developers can use that as they desire.
> 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 <=>.
Oh, so it's just saying that implementing __lessThan() in the future is not
blocked, as that would simply get checked before __compareTo() while
__compareTo() would be the first thing called for <=>. Gotcha. I'm good with
that.
--Larry Garfield
signature.asc
Description: This is a digitally signed message part.
