Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116771
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4525-g8883000b21-fm-20211221.001-g8883000b
Mime-Version: 1.0
Message-ID: <21fdd060-0e97-4fe2-aa1c-a196f334b8e3@www.fastmail.com>
In-Reply-To: 
 <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
References: 
 <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
Date: Mon, 03 Jan 2022 08:36:00 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Jan 2, 2022, at 6:13 PM, Jordan LeDoux wrote:
> Hello internals,
>
> I've opened voting on
> https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> close on 2022-01-17.
>
> To review past discussions on this RFC and the feature in general, please
> refer to:
>
> - https://externals.io/message/116611 | Current RFC discussion
> - https://externals.io/message/115764 | Initial RFC discussion
> - https://externals.io/message/115648 | Pre-RFC discussion and fact-finding
>
> Jordan

I have voted Yes on this RFC as well.

PHP right now is littered with inconsistencies between its various types.  Redesigning the whole thing is obviously impossible, but allowing objects to hook into behaving like other values piecemeal (as this RFC does) is probably the best option available.  Not every object will need every operator, and that's fine, but in places where they are useful, they will be *really* useful.

I just ran into a place 2 weeks ago where the <=> or == overrides would have saved me a ton of time and effort, and allowed objects to work with more existing utilities.  (In this case, in_array() with value objects, which right now is impossible without a ton more pointless work).  Just those alone justify the RFC for me.

I also believe this RFC handles more edge cases to nudge people toward good usage than any other proposal could.  I really don't see how it could do better, without relying on other, even more controversial unimplemented features that may never exist (method pattern matching).

I do think this is the best we'll be able to do on this front, it solves a real and present problem I do see in my own code, and it has clear extension points for the future (e.g., supporting arbitrary operator symbols if we ever decide to).  That's all we can ask for from an RFC, so this has my vote.

(I also find it odd to argue that it is bad because it will lead to confusing code, but at the same time argue it's bad because it doesn't allow arbitrary operator definitions.  Those seem mutually contradictory positions.)

--Larry Garfield