Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102538
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
References: <CAHFNTweakKC+=+UJCWfD0ONcsrVH7rEKrOhnWObeGD+7TBQLjQ@mail.gmail.com>
 <CAFMT4Nq45CKLfsOhLn6c9bzdDyYa2mkpQMuren5Kk=zZpDb-LQ@mail.gmail.com> <CALKiJKob0k+=oEsZch2gsHnX6f32bTK5fQOFN+Z93XxqEzpa3A@mail.gmail.com>
In-Reply-To: <CALKiJKob0k+=oEsZch2gsHnX6f32bTK5fQOFN+Z93XxqEzpa3A@mail.gmail.com>
Date: Sat, 30 Jun 2018 14:04:27 -0400
Message-ID: <CAHFNTwdyJmgUX3AOTm8XJp80oEOFbp9PV3R7bvXw2_n-o_FFqg@mail.gmail.com>
To: rowan.collins@gmail.com
Cc: levim@php.net, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a187d6056fdfcc12"
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: rudolf.theunissen@gmail.com (Rudolf Theunissen)

--000000000000a187d6056fdfcc12
Content-Type: text/plain; charset="UTF-8"

> I think it's fairly crucial that this proposal is NOT just about
overloading operators, it's about overloading *behaviour*

That is what this RFC is trying to achieve. Equivalent in behaviour, so
we're providing a way for a class to define how it compares or equates to
another value. We're not providing a way to override the meaning or
function of the comparison operators, and it's up to the implementor to
follow this advice. There's nothing stopping someone making `>` modify the
object. But that's the nature of user-defined behaviour of operators:
giving a developer more flexibility also increases the amount of weird
stuff they can do. The question is simply whether the value of the
flexibility is more than the cost of the potential for misuse.

We're proposing the ability for a user to determine how a class should be
compared to another value. The ability to change the semantics of the
comparison operators is an unavoidable side effect.

> If someone implements __compareTo() just to give some domain-specific
meaning to the <=> operator

That would be bad implementation on their part, and we should mention in
the documentation update that this is not the intended application.

> 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.

Currently they do attempt to convert to boolean and integer, respectively,
but that doesn't achieve much because you can still return nothing in
either case and the coercion would be 0 and false.

--

The decision whether to accept this will come down to the trade-off between
flexibility and potential for misuse. We're giving the developer more power
and responsibility by adding to the capability of the language, but that
can be said for any language-level change that has the potential for
misuse. I would personally opt for more flexibility, with clear direction
on the intended use, and trust that those who decide to leverage it know
what they're doing.


On Fri, 29 Jun 2018 at 13:35, Rowan Collins <rowan.collins@gmail.com> wrote:

> 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]
>

--000000000000a187d6056fdfcc12--