> On Sep 17, 2024, at 6:04 AM, Andreas Leathley <a.leath...@gmx.net> wrote: > > 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. > When you see a method call, you know 100% of the time that it calls a method.
Assuming operator overloading, when you see an operator used with variables, you will no longer be able to rely on your knowledge of how the operator work as it might use the built-in operator OR it might call a method. Most of the time it will be the former, occasionally the latter. And since a method would only be called occasionally I would likely get tired of searching to see if there is a method being called and just assume there isn't. Not smart, but having to track down potential methods for every operator use would just be far too tedious. > 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. > The more generic named the method, the more IDEs struggle with finding methods, and operators are about as generic as you can get. > 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). > ANY object could have an operator overload on `==` and/or `===` and have those behave differently. I also just checked and Symfony has many parameters type hinted as Stringable and numerous interfaces that extend Stringable. Any object that implements Stringable could also add operator overloads and introduce subtle bugs into those functions. Symfony has numerous interfaces that extend Countable. Any object that implements Countable could also add operator overloads and introduce subtle bugs into those functions. Symfony has numerous interfaces that extend ArrayAccess. Any object that implements ArrayAccess could also add operator overloads and introduce subtle bugs into those functions. Further — if operator overloads are added — there will likely be demand for more "-able" type interfaces, or some other way to make objects behave more like scalar types. If we have opt-in then code is safe. If we do not have opt-in then unintended consequences are possible, if not likely. > 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. > We will have to agree to disagree on that then. Look at what happened when is was added to C++; people when crazy with it and it was numerous years before the community moderated their behavior. > Many other languages have had operator overloading for many years of even > decades - are there really huge problems in those languages? > Depends on what you consider to be "huge" problems. Many people feel operator overloading is a cure for an ailment where the medicine is the worse than the disease. Just google "operator overloading considered harmful." But in case you can't be bothered to google, here are just three of many opinions: - https://medium.com/@fmmarzoa/say-no-to-operator-overloading-7b21aa06c518 <https://medium.com/@fmmarzoa/say-no-to-operator-overloading-7b21aa06c518> - https://cafe.elharo.com/programming/operator-overloading-considered-harmful/ <https://cafe.elharo.com/programming/operator-overloading-considered-harmful/> - https://www.oreilly.com/library/view/sams-teach-yourself/0672324253/0672324253_ch21lev1sec4.html <https://www.oreilly.com/library/view/sams-teach-yourself/0672324253/0672324253_ch21lev1sec4.html> > 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? > Besides the links above, my sources are personal experience over 30+ years of programming. > 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. > And I support that. Just have developers or yourself opt-in to use operators on your Money class. Requiring an opt-in is a safer way to go, and NOT requiring an opt-in means we would forever have to live with any downsides that opt-in would reign in. So how is requiring an opt-in a bad idea and not a reasonable compromise? > On Sep 17, 2024, at 1:22 PM, Jordan LeDoux <jordan.led...@gmail.com> wrote: > While I do not presume to speak for all voters (I don't even have voting > rights myself), my feeling from all of the conversations I have had over > almost the last 4 years is that implementing your suggestion would virtually > guarantee that the RFC is declined. Well, given that few have commented on the idea yet, it seems premature to make that assumption. Why not wait until we get more feedback rather than nix it up front? > You are suggesting providing a new syntax (which voters tend to be skeptical > of) to create a situation where more errors occur > (which voters tend to be skeptical of) So, type hinting is all about creating errors. Yet almost everyone on the list is super excited about adding more and better type hinting. Given that, I would argue that you are claim is, if not false, at least far too simplistic to be a valid claim. > to solve a problem which can be solved with existing syntax by simply type > guarding your code to not allow any objects near your operators (which voters > tend to be skeptical of) You mean you assume it can be solved with existing syntax. > for which I cannot find any code examples that explain the problem it is > solving (which voters tend to skeptical of). Frankly, it is difficult to come up with examples because examples are predicating on junior developers doing dumb things that would never occur to a senior developer because they know better. But I prepared one such hypothetical example using `function equals()` as a stand-in for `operator ==` so the code will run: https://3v4l.org/6GTKb#v8.3.11 I feel certain I could come up with several others, but I unfortunately have already exceeded my time allotment for the day. > On Sep 17, 2024, at 1:43 PM, Jordan LeDoux <jordan.led...@gmail.com> wrote: > > The problem I was trying to solve involved lots of things that cannot be > represented well by primitive types (which is presumably why they are classes > in the first place). Things like Complex Numbers, Matrices, or Money. Money > can be converted to a float of course (or an int depending on > implementation), but Money does not want to be added with something like > request count, which might also be an int. Or if it does, it probably wants > to know exactly what the context is. There are lots of these kinds of value > classes that might be representable with scalars, but would lose a lot of > their context and safety if that is done. > > On the other hand, Money would probably not want to be multiplied with other > Money values. What would Money squared mean exactly? Things like this are > very difficult to control for if all you provide is a way to control casting > to scaar types. Given your pushback you had on even having an opt-in for operator overload, why not instead prepare RFCs for built-in Complex Number, Matrix, and Money classes? That was what I argued three years ago yet no action was taken on it so I get the impression that not having operator overloading for those kind of classes is actually not that big of a deal as someone would have pushed a class-specific RFC in that 3 years time. As an aside, I think it would be a LOT more valuable to have a built-in standard that becomes always available as a starting point for everyone doing maths rather than having a bunch of different, incompatible and non-composable and edge-case buggy classes for these uses out on Github. -Mike
