Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
References: <CAHFNTweakKC+=+UJCWfD0ONcsrVH7rEKrOhnWObeGD+7TBQLjQ@mail.gmail.com>
 <CAFMT4Nq45CKLfsOhLn6c9bzdDyYa2mkpQMuren5Kk=zZpDb-LQ@mail.gmail.com>
 <CAFMT4NpEr592o_8g9PR1kEv2EG7H9AA+Rsm2hGjYBR_=X0F8JQ@mail.gmail.com> <CAHFNTwcQf+7B2Jb7ZjBFx625PN4ouRmf5+DjMWOWGB0KKzyRRg@mail.gmail.com>
Date: Wed, 27 Jun 2018 18:58:29 -0400
Message-ID: <CAHFNTwevL1aW498JpOhyeVPFq9Jhynnmmk5-Rpxebxo9zD8oMQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000407d3f056fa78e96"
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: rudolf.theunissen@gmail.com (Rudolf Theunissen)

--000000000000407d3f056fa78e96
Content-Type: text/plain; charset="UTF-8"

Hi everyone,

I've made some changes to the RFC and the implementation today to explain
some of the edge cases and combined behaviour better.

There are some issues towards the bottom of the RFC that I would really
like some opinions on. They all have decisions made but are not concrete,
so I'd like to know if anyone has strong opinions on them before they are
considered a final part of the RFC. I'm happy with the current state but
I'm very open to changing those decisions if there's a good enough reason
to.

See https://wiki.php.net/rfc/object-comparison#open_issues

Thank you

On Wed, 27 Jun 2018 at 18:53, Rudolf Theunissen <rudolf.theunissen@gmail.com>
wrote:

> In summary, I propose that return type constraints should be removed
>> which will allow us to pursue specific operator overloading at a later
>> point if we desire
>
>
> There are no return types or parameter types. The only requirement is that
> the function is public and not static.
>
>
> On Wed, 27 Jun 2018 at 15:21, Levi Morrison <levim@php.net> wrote:
>
>> On Wed, Jun 27, 2018 at 12:24 PM Levi Morrison <levim@php.net> wrote:
>> >
>> > On Tue, Jun 26, 2018 at 5:50 PM Rudolf Theunissen
>> > <rudolf.theunissen@gmail.com> wrote:
>> > >
>> > > Hi everyone,
>> > >
>> > > This is an RFC that is based on previous discussions here:
>> > > https://externals.io/message/102337
>> > >
>> > > RFC: https://wiki.php.net/rfc/object-comparison
>> > >
>> > > The implementation is tested and appears to be working as expected. :)
>> >
>> > I had some off-list contact with Rudi and generally have agreed with
>> > these changes.
>> >
>> > However, there may be some value in following Python's lead. In Python
>> > 2 they had a `__cmp__` magic method and in Python 3 they removed it
>> > and added all of these:
>> >
>> >    __lt__
>> >   __le__
>> >   __eq__
>> >   __ne__
>> >   __gt__
>> >   __ge__
>> >
>> > This permits things such as NumPy to overload < to do an element-wise
>> > comparison of the members; something like this:
>> >
>> >     np.array([1, 3, 5, 7]) < np.array([2, 1, 6, 6])
>> >     // evaluates to np.array([true, false, true, false)
>> >
>> > If we pursue this Pythonic route then we would also need methods for +
>> > - * / % etc. I do not want to derail the conversation too much, but it
>> > does seem opportune to discuss operator overloading more generally.
>>
>> We would still need `__compareTo` if we did operator overloading
>> because we have the `<=>` operator. Rudi has pointed out that because
>> of this we should be able to overload individual operators at a later
>> point without backwards compatibility issues if we so choose. I think
>> this is true if we do not constrain the return types.
>>
>> In summary, I propose that return type constraints should be removed
>> which will allow us to pursue specific operator overloading at a later
>> point if we desire; an author can always add `: bool` or `: int` to
>> their own methods if they so desire.
>>
>

--000000000000407d3f056fa78e96--