Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102373
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.46 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>
In-Reply-To: <CAHFNTwffwu=GTi3u=gS5nNf0AgjywPPE-2YJNpXZpKte__Wh6w@mail.gmail.com>
Date: Fri, 22 Jun 2018 13:55:55 -0400
Message-ID: <CAHFNTweymOruLojRwcfhsAZTDrPwvQA86cK3cBziPd5diba3TQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000ff091e056f3ebeed"
Subject: Re: [PHP-DEV] Equality and relative ordering of objects
From: rtheunissen@php.net (Rudi Theunissen)

--000000000000ff091e056f3ebeed
Content-Type: text/plain; charset="UTF-8"

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
>>
>

--000000000000ff091e056f3ebeed--