Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121425
Content-Type: multipart/alternative;
 boundary="------------p4xVImhWkuEoPdnORnlrlCJt"
Message-ID: <712f1499-77cd-4897-bc8b-e13468d5c598@processus.org>
Date: Thu, 19 Oct 2023 09:14:22 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: someniatko <someniatko@gmail.com>, php internals <internals@lists.php.net>
References: <CABAhh3FtvJ3TMF6R8Ot1o+OzS+SMOw37U3uehgCWPrP7guHB1A@mail.gmail.com>
 <f90cb6db-d816-4a90-86d4-2760b7e721c8@processus.org>
 <CAMrTa2EHx3-WG_7qAPYSVRFJxs+DzFbMRd=0jtiHi1UdH+Oa_Q@mail.gmail.com>
In-Reply-To: <CAMrTa2EHx3-WG_7qAPYSVRFJxs+DzFbMRd=0jtiHi1UdH+Oa_Q@mail.gmail.com>
Subject: Re: [PHP-DEV] Custom object equality
From: pierre-php@processus.org (Pierre)

--------------p4xVImhWkuEoPdnORnlrlCJt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Le 18/10/2023 à 22:22, Jordan LeDoux a écrit :
>
> While I (obviously) appreciate the goal of the proposal here since I 
> wrote the gigantic operator overload RFC the last time it was 
> proposed, I do not support this idea here for one very simple reason: 
> it is a clunky, work-around implementation to try and get the benefits 
> of operator overloads without actually doing it.
Even if I don't really like operator overload, I would very much prefer 
the gigantic operator overload to pass than a band-aid patch with a new 
operator, I'm all in for consistency.
>
> The need to control comparisons is real and obvious. So long as voters 
> are categorically opposed to actual operator overloads no matter the 
> implementation, as represented here by you Pierre but by no means a 
> position that only you hold, I don't think we should be looking for 
> ways to get the functionality through hacks like this. It may get 
> passed in the short term and get PHP developers the equality 
> comparison control that objects desperately need, but it makes all 
> future improvements almost impossible to do.

Maybe I don't master english enough and I can speak to strictly 
sometime. If an operator overload RFC that doesn't have any blind spot 
or weird edge case happens, I'd be happy to see it pass, at least it 
would close bike shedding around this topic and life would continue happily.

I can't vote, but if I could, I wouldn't vote against a proper, robust, 
and easy to debug for developers operator overload RFC, I would simply 
abstain, because even if I personally don't like it, lots of people want 
it and I'm simply one among millions of PHP users, I don't want anyone 
to be frustrated.

The most important thing in my previous message I wanted to say was that 
the "~" symbol refers to something "approximate" in many contexts, in my 
opinion it's not the right choice for an equality operator. My opinion 
is either go for a full-on proper operator overload or simply don't.

Regards,

--

Pierre


--------------p4xVImhWkuEoPdnORnlrlCJt--