Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121452
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1048-g9229b632c5-fm-20231019.001-g9229b632
MIME-Version: 1.0
Message-ID: <53753a0f-04c2-442e-821b-20f107313a13@app.fastmail.com>
In-Reply-To: <97e67da5-d54a-403d-be4d-ed275240442a@gmail.com>
References: 
 <CABAhh3FtvJ3TMF6R8Ot1o+OzS+SMOw37U3uehgCWPrP7guHB1A@mail.gmail.com>
 <97e67da5-d54a-403d-be4d-ed275240442a@gmail.com>
Date: Mon, 23 Oct 2023 16:34:10 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Custom object equality
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Oct 23, 2023, at 3:14 PM, Dik Takken wrote:
> On 18-10-2023 14:50, someniatko wrote:
>> This approach allows combining
>> - no BC break - `~=` is a new syntax which is unavailable in older PHP
>> versions
>> - explicitly showing an intent that objects are compared using a custom
>> comparison, rather than standard PHP one
>> - allow to skip writing boilerplate equals() methods which just forward
>> equals() to the nested objects
>> - standardize such comparisons on the language level
>> 
>> Of course how exactly this operator looks may be changed, `~=` is just an
>> example.
>> 
>> WDYT?
>> 
>> Regards,
>> Illia / someniatko
>> 
>
> One thing to keep in mind is that operator overloading already exists in 
> PHP. And it is already in use in userland PHP too, for example when 
> comparing DateTime objects. The limitation is that it only works for 
> some objects: Those that are implemented in an extension.
>
> To me, the obvious way forward would be to lift this limitation. But... 
> several attempts to do so have failed to pass. People are hesitant to 
> unleash full operator overloading power to PHP developers.
>
> So, perhaps a simplified version of the RFC by Jordan LeDoux, limited to 
> the `==` operator only, would stand a chance? It would allow the 
> community to try their hands on this one (highly valuable) operator 
> overload. PHP 9 is coming and provides a great opportunity.
>
> I also like the idea from Pierre to provide interfaces. Some people 
> prefer an explicit method call over an operator doing magic things, 
> which I fully understand. Perhaps we could allow both?
>
> Regards,
> Dik

I would recommend including ==, <, >, <=, >= all in the initial design, as they do interact.  I've said in the past that I'd welcome a reduced-scope version as a stepping stone.

Jordan's RFC explained in detail why interfaces are not viable, which is why we have to use magic methods (with or without a special keyword) instead:

https://wiki.php.net/rfc/user_defined_operator_overloads#why_not_interfaces

(Seriously, it has an extensive FAQ.  It's one of the more detailed and supported RFCs we've seen.)

--Larry Garfield