Re: Equality and relative ordering of objects
| From: | Levi Morrison | Date: | Sun, 24 Jun 2018 17:59:47 +0000 |
| Subject: | Re: Equality and relative ordering of objects | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-102397@lists.php.net to get a copy of this message | ||
On Sun, Jun 24, 2018 at 11:28 AM Rudi Theunissen <rtheunissen@php.net> wrote:
>
> 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.
In these schemes I am not understanding how to specify that something
is not equal, not ordered, and should not fall back to something else.
Consider things like UUIDs and other identifiers where equality is
desired and ordering does not make sense. Other languages (most? all?)
separate equality and ordering for this reason; I think we ought to do
the same.