On 17.09.24 11:14, Mike Schinkel wrote:
How would a developer know if they are using an object that has operators, unless they study all the source code or at least the docs (assuming there are good docs, which there probably are not?)
How is that different from using a method on an object? Operators are roughly speaking a different syntax for methods, and if you use an object method, you have to know about it or look up what it does. Also, getting to the implementation of operators would likely be just as easy as looking up methods nowadays, because IDEs would support that kind of lookup.
Situation where there is free-reign userland operator overloading: Junior developer Joe is using Symfony and learns about this great new operator overload feature so decides to implement all the operators for all his objects, and now he wants to start passing his objects to Symphony code. Joe decides to be clever and implement "/" to concatenate paths strings together but doesn't type his properties, and he ends up passing them to a Symfony function that uses `/` for division, and his program crashes with very cryptic error messages. He reports them to the Symfony developers, and it wastes a bunch of time for everyone until they finally figure out why it failed, because nobody every considered a developer would do such a thing.
Most framework and library code is by now type-hinted - I would have understood this argument when operator overloading would be implemented into PHP 5.x, where many classes and functions got values and had no enforced types, so they might have expected an int, yet an object with operator overloading might work but in weird ways, because there were no type hints for int. I cannot see this situation now at all - if a Symfony component wants an int, you cannot pass in an object. If a Symfony component wants a Request object, it will not use operators that it does not expect to be there, even if you would extend the class and add operator support. Using operators implies you know you can use operators, otherwise it will be a fatal error (except for comparisons). From your arguments it also seems you are afraid everybody will use operator overloading excessively and unnecessarily. This seems very unlikely to me - it is not that useful a feature, except for certain situations. Many other languages have had operator overloading for many years of even decades - are there really huge problems in those languages? If yes, maybe PHP can learn from some of the problems there (which I think the original RFC tried to carefully consider), but as far as I know the usage of operator overloading is niche in languages which support it, depending on use case - some people like it, some don't, but they do not seem to be a big problem for these languages or their code in general. Maybe you have some sources on actual problems in other languages? Personally I would love my Money class to finally have operators instead of the current "plus", "minus", "multipliedBy" (and so on) methods which are far less readable. I would only use operator overloading on a few specific classes, but for those the readability improvement would be huge. Also, being able to override comparison operators for objects would be very useful, because currently using == and === with objects is almost never helpful or sufficient.
