Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102549
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.51 as permitted sender)
MIME-Version: 1.0
References: <CAHFNTweakKC+=+UJCWfD0ONcsrVH7rEKrOhnWObeGD+7TBQLjQ@mail.gmail.com>
 <CAFMT4Nq45CKLfsOhLn6c9bzdDyYa2mkpQMuren5Kk=zZpDb-LQ@mail.gmail.com>
 <CALKiJKob0k+=oEsZch2gsHnX6f32bTK5fQOFN+Z93XxqEzpa3A@mail.gmail.com>
 <CAHFNTwdyJmgUX3AOTm8XJp80oEOFbp9PV3R7bvXw2_n-o_FFqg@mail.gmail.com> <91F0875C-74EC-4115-83F9-5E87A02051C9@gmail.com>
In-Reply-To: <91F0875C-74EC-4115-83F9-5E87A02051C9@gmail.com>
Date: Sun, 1 Jul 2018 14:45:03 -0400
Message-ID: <CAHFNTwcteMFuwWwumCM=nm5NyDmBORX4YkGtpSGY8t+h_LN9ww@mail.gmail.com>
To: rowan.collins@gmail.com
Cc: levim@php.net, internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000048b20e056ff47b04"
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: rudolf.theunissen@gmail.com (Rudolf Theunissen)

--00000000000048b20e056ff47b04
Content-Type: text/plain; charset="UTF-8"

>
> I think what I was suggesting is that if people in future want to overload
> the operators specifically, we would want to provide an overload for <=>
> that was separate from __compareTo, so that you could overload that without
> breaking things like sorting.


I think it would be confusing to have both, or to have <=> not be aligned
with __compareTo, because they are semantically equivalent. By overloading
<=>, you have to also override comparison. Separating those is a recipe for
confusion.

Apologies if this is covered in the RFC, but does that apply wherever they
> are used? For instance, what will the following code do?
> class SpaceStation {
>      public $shape;
>      public function __construct($shape='[]') {
>           $this->shape = $shape;
>      }
>      public function __compareTo($other) {
>           return new self($this->shape . '>=<' . $other->shape);
>      }
> }
> $a = new SpaceStation;
> $b = new SpaceStation;
> $c = $a <=> $b; // Error? 0?
> echo $c->shape; // or will this echo '[]>=<[]'?
> $d = $a < $b; // Same result?
> $list = [$a, $b, $c, $d];
> sort($list); // Or will the error only be raised here?


When you use the `<=>` operator, the return value is normalised to either
-1, 0 or 1 which is consistent with the current behaviour. So the object
you're returning in `compareTo` will be converted to an integer(1) which
will make `$c` be `1`. Attempting to call `echo $c->shape` then makes no
sense.

`$a < $b` will be false because according to your return of `1`, `$a` would
be greater.

Sorting would then consider the LHS to always be greater also.

One thing that your example brings up is that `<=>` is not exactly
equivalent to calling `__compareTo` directly, which would just return the
raw value. This is exciting because it's a new issue that I'll add to the
RFC for consideration. Ideally we would like the operator and the magic
method to behave exactly the same, but that doesn't seem like a viable
option because we wouldn't want to magically translate the return value of
a function you're calling directly. The only option then is to simply
advise that <=> will normalise the return value of `__compareTo`. I'm
personally okay with that behaviour if it means the convention of the
return value of <=> remains intact.

--00000000000048b20e056ff47b04--