Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102530
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.208.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFMT4Nq45CKLfsOhLn6c9bzdDyYa2mkpQMuren5Kk=zZpDb-LQ@mail.gmail.com>
References: <CAHFNTweakKC+=+UJCWfD0ONcsrVH7rEKrOhnWObeGD+7TBQLjQ@mail.gmail.com>
 <CAFMT4Nq45CKLfsOhLn6c9bzdDyYa2mkpQMuren5Kk=zZpDb-LQ@mail.gmail.com>
Date: Fri, 29 Jun 2018 18:35:58 +0100
Message-ID: <CALKiJKob0k+=oEsZch2gsHnX6f32bTK5fQOFN+Z93XxqEzpa3A@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: Rudolf Theunissen <rudolf.theunissen@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e4ecc7056fcb471f"
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000e4ecc7056fcb471f
Content-Type: text/plain; charset="UTF-8"

On 27 June 2018 at 19:24, Levi Morrison <levim@php.net> wrote:

> 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)
>


In my opinion, this is exactly the kind of messy operator overloading we
should avoid, but if we DO want it, then its purpose is to over-ride the
syntax, not the meaning, of the operator; so "overloaded <=>" would NOT be
the same as "overloaded comparison".

I think it's fairly crucial that this proposal is NOT just about
overloading operators, it's about overloading *behaviour* which occurs
throughout the language, and as such I think this statement from the RFC is
incorrect:

> __compareTo is equivalent to <=> and __equals is equivalent to ==

If someone implements __compareTo() just to give some domain-specific
meaning to the <=> operator, what will happen when someone passes those
objects to sort()? If someone decides they want to return an object from
__equals(), how will switch statements behave? And so on...

Because of that, I would much rather these functions did enforce a return
type. Note that __toString() generates an error for an incorrect return
type when used, and __sleep() raises a Notice and serializes Null instead
of the object. 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.

Then, if we want the ability to override the <=> operator specifically,
that can be added later, and users can return whatever type they want
without breaking all the other places where __compareTo() is called.

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000e4ecc7056fcb471f--