Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102390
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.41 as permitted sender)
MIME-Version: 1.0
References: <CAHFNTwccchXDWnpy=rmxRJ+r6rJrr_gs3ojxim+rPQPsKPVvLA@mail.gmail.com>
 <CA+kxMuR7d5GmVxC0v+=+W_TAMLawunsKSCF73cawMbU5jKffQQ@mail.gmail.com>
 <CAHFNTwcbY=nprJQw+U3bNyuO12PT4=hFgnsmdKpWrmabS3Kr5w@mail.gmail.com>
 <CA+kxMuT09fhHOc1NpZhfsFkmq2vtm1apK3Ktj4ysN5etubRPCQ@mail.gmail.com>
 <CAHFNTwffwu=GTi3u=gS5nNf0AgjywPPE-2YJNpXZpKte__Wh6w@mail.gmail.com>
 <CAHFNTweymOruLojRwcfhsAZTDrPwvQA86cK3cBziPd5diba3TQ@mail.gmail.com> <CAHFNTwdq1eWVhFxdkdsRi-fdwqVML97pWxdssjbneBc2Op0Q6g@mail.gmail.com>
In-Reply-To: <CAHFNTwdq1eWVhFxdkdsRi-fdwqVML97pWxdssjbneBc2Op0Q6g@mail.gmail.com>
Date: Sun, 24 Jun 2018 10:10:55 -0400
Message-ID: <CAHFNTwfac=F+55jCFSfqhsZ5odypjmdNem7ixXPsrZfny97Jng@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000a5ac0056f63d62a"
Subject: Re: [PHP-DEV] Equality and relative ordering of objects
From: rtheunissen@php.net (Rudi Theunissen)

--0000000000000a5ac0056f63d62a
Content-Type: text/plain; charset="UTF-8"

Here is a WIP implementation of `__compareTo`, with some decent tests.

https://github.com/php/php-src/compare/master...rtheunissen:rt-compare-to-magic-method?diff=unified

On Fri, 22 Jun 2018 at 17:03, Rudi Theunissen <rtheunissen@php.net> wrote:

> On further investigation, I'm not sure if we need both `__equals` and
> `__compareTo`,
> even with all the talk about contexts and the fact that an object can be
> tested for
> equality and not necessarily ordering as well. If we take out the
> `__equals` method
> and only include `__compareTo`, we can allow the user to return NULL to
> indicate
> that the object doesn't support the comparison that is being done. So the
> return
> values of `__compareTo` then becomes:
>
> ```
>  1:    Greater than
> -1:    Less than
>  0:    Equal to, ==
>  NULL: Unsupported, fall back to default behaviour.
> ```
> In the case of an object returning NULL, we can fall back to the default
> behaviour,
> which is equivalent to the `compare` handler returning FAILURE, which then
> falls
> through to the `compare_objects` handler.
>
> I think this will be less confusing and much easier to implement.
>
> It's interesting to note that Java's `Comparable` interface considers a
> 0-return
> to indicate equality, where a `==` would compare references in the same
> way
> PHP's `===` would. So in dropping the `__equals` method, we're slightly
> more
> aligned with Java, even though that's not exactly the goal here. :p
>
> On Fri, 22 Jun 2018 at 13:55, Rudi Theunissen <rtheunissen@php.net> wrote:
>
>> What's the best place to override == internally? `do_operation` or a new
>> object handler?
>> I'd like to separate equality from compare_function.. or should we ignore
>> `__equals `
>> and assume that the values are equal if `__compareTo` returns 0?
>>
>> Here's some context: I'm modifying `is_equal_function` to check for an
>> `__equals`
>> implementation if the value is an object, which I think should work, but
>> it's not clear how
>> an internal object (like the ds structures, for example) should override
>> ==.
>>
>> `do_operation` seems like a good choice for this, but I wanted to check
>> with you all first.
>>
>>
>>
>> On Fri, 22 Jun 2018 at 13:06, Rudi Theunissen <rtheunissen@php.net>
>> wrote:
>>
>>> > Yes, that's the type of thing that I think needs to be included as
>>> > part of the RFC.
>>> >
>>> > Including a list of all the (or at least the important) functions that
>>> > would be affected by this RFC should be made both for clarity and so
>>> > that people can think through any edge cases.
>>>
>>>
>>> Absolutely. I was hoping to gather some thoughts and opinions first
>>> while I
>>> work on the implementation before I submit an official RFC. I'll make
>>> sure to
>>> include what you've mentioned, I completely agree.
>>>
>>> On Fri, 22 Jun 2018 at 11:14, Dan Ackroyd <danack@basereality.com>
>>> wrote:
>>>
>>>> On 22 June 2018 at 12:31, Rudi Theunissen <rtheunissen@php.net> wrote:
>>>>
>>>> >
>>>> >> I think if you want to push the RFC forward, a really quite strong
>>>> >> case needs to be made for why having it be a language level feature
>>>> is
>>>> >> so much better (or even at all better) than having it be implemented
>>>> >> in userland.
>>>>
>>>> >
>>>> >
>>>> > 1. You can't override the behaviour of `<`, `<=`, `>`, `>=`, `==`,
>>>> `!=` with
>>>> > a userland implementation.
>>>> > 2. Therefore, you won't be able to affect the internals of array
>>>> functions
>>>> > like `in_array`, `sort` etc.
>>>>
>>>>
>>>> Yes, that's the type of thing that I think needs to be included as
>>>> part of the RFC.
>>>>
>>>> Including a list of all the (or at least the important) functions that
>>>> would be affected by this RFC should be made both for clarity and so
>>>> that people can think through any edge cases.
>>>>
>>>> cheers
>>>> Dan
>>>>
>>>

--0000000000000a5ac0056f63d62a--