Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102550
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 22:00:39 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAHFNTwcteMFuwWwumCM=nm5NyDmBORX4YkGtpSGY8t+h_LN9ww@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> <91F0875C-74EC-4115-83F9-5E87A02051C9@gmail.com> <CAHFNTwcteMFuwWwumCM=nm5NyDmBORX4YkGtpSGY8t+h_LN9ww@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: internals@lists.php.net
Message-ID: <A1F9A95F-AE90-4BCA-AA00-5FD6EF406E3C@gmail.com>
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: rowan.collins@gmail.com (Rowan Collins)

On 1 July 2018 19:45:03 BST, Rudolf Theunissen <rudolf=2Etheunissen@gmail=
=2Ecom> wrote:
>>
>> 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
><=3D>
>> that was separate from __compareTo, so that you could overload that
>without
>> breaking things like sorting=2E
>
>
>I think it would be confusing to have both, or to have <=3D> not be
>aligned
>with __compareTo, because they are semantically equivalent=2E By
>overloading
><=3D>, you have to also override comparison=2E Separating those is a reci=
pe
>for
>confusion=2E

That's the point though: with operator overloading as defined in many lang=
uages, they're only semantically equivalent if the person overloading the o=
perator wants them to be=2E The most well-known example is probably the C++=
 operator >> which for primitives is a bit shift, but is overloaded for inp=
ut and output to streams=2E

If, on the other hand, operator overloading was added but constrained by t=
he language to certain return values, there would be very little to be gain=
ed by overloading each comparison separately - all the extra overloads woul=
d have to return boolean anyway=2E


>When you use the `<=3D>` operator, the return value is normalised to
>either
>-1, 0 or 1 which is consistent with the current behaviour=2E So the
>object
>you're returning in `compareTo` will be converted to an integer(1)

That makes perfect sense to me, thanks=2E Just to reiterate, it's *not* wh=
at fans of free-form operator overloading would want, but I think it's the =
right behaviour for this feature=2E


>One thing that your example brings up is that `<=3D>` is not exactly
>equivalent to calling `__compareTo` directly, which would just return
>the
>raw value=2E

Yeah, that's a good point=2E Directly calling magic methods is always a bi=
t peculiar, but I think a note in the manual is probably enough=2E


Regards,

--=20
Rowan Collins
[IMSoP]