On Wed, Oct 18, 2023 at 6:03 AM Pierre <pierre-...@processus.org> wrote:
> Le 18/10/2023 à 14:50, someniatko a écrit : > > Hi internals, > > > > 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? > > I'm not fond of operator overloading, I actually quite hate it, I like > the expressiveness of an equals() method. > > I would very much prefer to have a set of standard interfaces such as > Comparable { compareTo($other): int } or Equatable { equals($other): > bool; } which the standard API and userland libraries could make use of. > > In all cases, I don't like the ~= choice because in my mind it literally > translates to "is approximately/barely/maybe comparable to". > > By the way, please do not use abbreviations such as WDYT, I'm not a > native english speaker and I don't know all abbreviations, I had to > duckduckgo' it. > > Regards, > > -- > > Pierre > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > 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. 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. someniatko: If voters don't want operator overloads, then voters don't get the features of operator overloads. It's very much that simple. If you want this feature, try and change minds (ha ha good luck). "Operator overloads don't fit a language like PHP"... despite the fact that Python is the language most like PHP in many ways and has some absolutely crazy operator overloads. "Operator overloads make operators impossible to understand"... despite the fact that this is already the case with existing operators and magic methods. "There is no use case"... despite the fact that this gets suggested by a different person like clockwork AT LEAST every version because it is something they would use. Honestly I would give up on advocating for operator overloads someniatko and just move to a language that has them like Python. That's what I did. Your sanity will thank me. Jordan