Re: [VOTE] User Defined Operator Overloads
| From: | Larry Garfield | Date: | Mon, 03 Jan 2022 14:36:00 +0000 |
| Subject: | Re: [VOTE] User Defined Operator Overloads | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116771@lists.php.net to get a copy of this message | ||
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