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
