The idea behind the nullable return is to allow for partial support, where
you might want to check for
equality but ignore ordering. You can't return nothing or NULL if we
normalise to -1,0,1 because NULL
would be 0 and therefore indicate that the values are equal.
We could require that the user always returns an integer, and suggest -1 to
be returned when there's no
clear definition for ordering. The null return was to avoid returning that
-1 when ordering isn't defined.
```
class Equatable {
public function __compareTo($other) {
if ($other instanceof self && $this->prop === $other->prop) {
return 0;
}
// No logical ordering exists, so we're not concerned?
}
}
```
As it stands, we have a few options here:
1. Allow anything to be returned and normalise to -1, 0 and 1.
2. Require an integer, error when anything else is returned, suggest -1 as
a comparison-not-defined convention.
3. Use NULL (or void return) as an indication that the comparison couldn't
be made, fall through to compare_objects.
4. Use NULL (or void return) as an indication that the comparison couldn't
be made, internal error.
My vote at the moment would go to #3 or #4 because it's the most flexible
and the NULL is an edge-case.
On Sun, 24 Jun 2018 at 11:30, Levi Morrison <le...@php.net> wrote:
> On Sun, Jun 24, 2018 at 8:11 AM Rudi Theunissen <rtheunis...@php.net>
> wrote:
> >
> > Here is a WIP implementation of `__compareTo`, with some decent tests.
> >
> >
> https://github.com/php/php-src/compare/master...rtheunissen:rt-compare-to-magic-method?diff=unified
>
> Help me understand the nullable return. If you are defining this
> operator then by definition you don't want the standard behavior, so
> why is returning null helpful? Seems like implementors ought to throw.
>
