Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102544
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.177 as permitted sender)
Date: Sun, 01 Jul 2018 00:07:34 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAHFNTwdyJmgUX3AOTm8XJp80oEOFbp9PV3R7bvXw2_n-o_FFqg@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Rudolf Theunissen <rudolf.theunissen@gmail.com>
CC: levim@php.net,internals@lists.php.net
Message-ID: <91F0875C-74EC-4115-83F9-5E87A02051C9@gmail.com>
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: rowan.collins@gmail.com (Rowan Collins)

On 30 June 2018 19:04:27 BST, Rudolf Theunissen <rudolf=2Etheunissen@gmail=
=2Ecom> wrote:
>We're proposing the ability for a user to determine how a class should
>be
>compared to another value=2E The ability to change the semantics of the
>comparison operators is an unavoidable side effect=2E

Absolutely, I agree with the intent of this RFC=2E I think what I was sugg=
esting is that if people in future want to overload the operators specifica=
lly, we would want to provide an overload for <=3D> that was separate from =
__compareTo, so that you could overload that without breaking things like s=
orting=2E


>> I think __compareTo() and __equals() could act more like a return
>type
>hint, and either throw a TypeError straight away, or attempt to coerce
>to
>the correct type and throw a TypeError on failure=2E
>
>Currently they do attempt to convert to boolean and integer,
>respectively,
>but that doesn't achieve much because you can still return nothing in
>either case and the coercion would be 0 and false=2E

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=3D'[]') {
          $this->shape =3D $shape;
     }
     public function __compareTo($other) {
          return new self($this->shape =2E '>=3D<' =2E $other->shape);
     }
}

$a =3D new SpaceStation;
$b =3D new SpaceStation;

$c =3D $a <=3D> $b; // Error? 0?
echo $c->shape; // or will this echo '[]>=3D<[]'?

$d =3D $a < $b; // Same result?

$list =3D [$a, $b, $c, $d];
sort($list); // Or will the error only be raised here?



>The decision whether to accept this will come down to the trade-off
>between
>flexibility and potential for misuse=2E=20

Absolutely, and for what it's worth (which isn't much) I'm +1 on this, if =
it's not documented as operator overloading (which I think is a separate fe=
ature) and can't be used to produce values outside the expected type (due t=
o coercion or errors)=2E

Regards,

--=20
Rowan Collins
[IMSoP]