On Mon, Oct 23, 2023, at 3:14 PM, Dik Takken wrote: > On 18-10-2023 14:50, someniatko wrote: >> 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? >> >> Regards, >> Illia / someniatko >> > > One thing to keep in mind is that operator overloading already exists in > PHP. And it is already in use in userland PHP too, for example when > comparing DateTime objects. The limitation is that it only works for > some objects: Those that are implemented in an extension. > > To me, the obvious way forward would be to lift this limitation. But... > several attempts to do so have failed to pass. People are hesitant to > unleash full operator overloading power to PHP developers. > > So, perhaps a simplified version of the RFC by Jordan LeDoux, limited to > the `==` operator only, would stand a chance? It would allow the > community to try their hands on this one (highly valuable) operator > overload. PHP 9 is coming and provides a great opportunity. > > I also like the idea from Pierre to provide interfaces. Some people > prefer an explicit method call over an operator doing magic things, > which I fully understand. Perhaps we could allow both? > > Regards, > Dik
I would recommend including ==, <, >, <=, >= all in the initial design, as they do interact. I've said in the past that I'd welcome a reduced-scope version as a stepping stone. Jordan's RFC explained in detail why interfaces are not viable, which is why we have to use magic methods (with or without a special keyword) instead: https://wiki.php.net/rfc/user_defined_operator_overloads#why_not_interfaces (Seriously, it has an extensive FAQ. It's one of the more detailed and supported RFCs we've seen.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
