Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102502
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
References: <CAHFNTweakKC+=+UJCWfD0ONcsrVH7rEKrOhnWObeGD+7TBQLjQ@mail.gmail.com>
 <CAFMT4Nq45CKLfsOhLn6c9bzdDyYa2mkpQMuren5Kk=zZpDb-LQ@mail.gmail.com>
In-Reply-To: <CAFMT4Nq45CKLfsOhLn6c9bzdDyYa2mkpQMuren5Kk=zZpDb-LQ@mail.gmail.com>
Date: Wed, 27 Jun 2018 13:21:25 -0600
Message-ID: <CAFMT4NpEr592o_8g9PR1kEv2EG7H9AA+Rsm2hGjYBR_=X0F8JQ@mail.gmail.com>
To: rudolf.theunissen@gmail.com
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: levim@php.net (Levi Morrison)

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.