Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102502
Return-Path: <morrison.levi@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 25041 invoked from network); 27 Jun 2018 19:21:42 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 27 Jun 2018 19:21:42 -0000
Authentication-Results: pb1.pair.com header.from=levim@php.net; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=morrison.levi@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
X-PHP-List-Original-Sender: morrison.levi@gmail.com
X-Host-Fingerprint: 209.85.215.48 mail-lf0-f48.google.com  
Received: from [209.85.215.48] ([209.85.215.48:40435] helo=mail-lf0-f48.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 53/92-01794-4C3E33B5 for <internals@lists.php.net>; Wed, 27 Jun 2018 15:21:42 -0400
Received: by mail-lf0-f48.google.com with SMTP id q11-v6so2379801lfc.7
        for <internals@lists.php.net>; Wed, 27 Jun 2018 12:21:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=L7i7qYlLOItE8NKo0RzQB3wxMsHN4tTk/BH7Vhb/ybg=;
        b=c9PZWRsZDmWdQkjY9zbFp8Lu2IQWy84AGwm0mCdM6bzTT7Jx5tEFdmwINkWn9Nn38o
         zG7rjMIDY875WVRGmpJtuRoREXGyjRunWilJEYXfZUAQ22567hP4K0OqxABoptbMmv1R
         dItEbxzV++ocoINiNyPnlBafAdjwixBBPv+6xCQuQijJuKO9SL0C+rpryJV/UGShp5R0
         SB+uEtgUcM1fpwTGE8AQQDTL4eZmlEMfjyTJNCtxR4vZQbF0zLgclsKUnlTtOCVI632/
         36lBNC1i3EZOzmGCgsZr2ogDTGtsolQEdXNm+OV2w6jA9mW65NTH4kHQ6zaiv1tA+Y2H
         F6gQ==
X-Gm-Message-State: APt69E2D2bf25KhbPNlqXrdFderwaIY1Dud0cqAHseCE0LUP34Fc5wI9
	kCm7F5gE336VE3TKltF98JSBYLK41ZdtnVTZDXQ=
X-Google-Smtp-Source: AAOMgpcfzZIcwfryTBuWWkkLrWYQBLpCQd5TWTxIJIaESRYRDKv0IG8snoRejUhPAb91Q9/ut0Xaj27wVMT4IDHgpNk=
X-Received: by 2002:a19:4895:: with SMTP id v143-v6mr3927014lfa.82.1530127297893;
 Wed, 27 Jun 2018 12:21:37 -0700 (PDT)
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.