On Tue, Sep 17, 2024 at 3:44 PM Mike Schinkel <m...@newclarity.net> wrote:
> 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://cafe.elharo.com/programming/operator-overloading-considered-harmful/ > - > 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 > I really wish you would read the things that I have written. 1. No objects would be able to overload the `===` operator, because that operator was not included in the RFC intentionally. 2. The current semantics of the `==` with objects are possibly used by some, but in practice from what I have seen and researched, are mostly so useless that they aren't used. But, even so, the comparison operators in the original RFC actually DO fall back to the existing behavior if no overload is present. 3. I don't know how else to explain this to you, but the existence of an operator in your code does NOT mean you would now need to do more work if you do not want to take advantage of operator overloads, even without an opt-in. Currently using objects with an operator results in a fatal error. Since you presumably have written code that can run in the last 30+ years of your experience, you have somehow avoided this. I presume you have avoided this situation by paying attention to the types of your variables. You may continue to do the same thing you MUST do now, and you will never encounter an operator overload. Ever. 4. None of the Symfony code that allows Stringable or Countable will suddenly produce new bugs without intentionally adding operators. I know this because the code currently does not produce errors, and currently any object that is Stringable and/or Countable will produce errors when it encounters any of the operators specified in the original RFC (excluding comparisons, which I have mentioned). ArrayAccess.... perhaps? Arrays can use `+` to union, and I'm not sure off the top of my head if ArrayAccess also does this. But that's an internal implementation that could be forced to remain the same fairly trivially if so. 5. I addressed this multiple times in my original RFC and the discussion surrounding it, but C++ is the most useless analogue anyone could choose for what I am proposing, and also just HAPPENS to be the language with the most negative impact from its operator overload implementation. I noticed this in my research prior to the RFC (which is the point of such research), and I made design choices SPECIFICALLY to avoid that and then communicated that to everyone via multiple channels including this mailing list and the original RFC. The vast majority of trouble that C++ operator overloads cause are related to overloads with pointers. Pointers do not exist in PHP, and their closest analogue (by-ref) are specifically not possible with overloads to prevent that very problem. 6. The articles you linked to about the evils of operator overload seem to be essentially making the point "people will misuse operator overloading". Sure. In fact the RFC I wrote had a section dedicated to that. People will misuse ANYTHING. I don't see that on its own as a legitimate reason to avoid a feature that has legitimate uses. I spent a lot of time researching this aspect of it in different developer communities, and my conclusion eventually was "most developer communities for languages that have operator overloads do not appear to see them as a particularly troublesome source of quirks, bugs, and confusion". I don't think that the Python or C# communities for instance would support removing the feature, even if there were a way to magically fix the BC issues it would cause. It is seen as a useful but niche feature, which is exactly what it is. 7. Your opt-in concept is a bad idea because it creates multiple switchable modes for the VM to run in, which is something that I think most developers would find MUCH more mentally taxing than simply adjusting to the new feature. 8. It is not merely an "assumption" that existing syntax can solve the issue you are trying to solve. The following operators ALWAYS result in a fatal error when used with an object that doesn't have an overload: `+`, `-`, `*`, `/`, `%`, `**`, `^`, `&`, `|`, `<<`, `>>`, `~`. These operators are currently used in code that does not produce errors. Ergo, there is an existing syntax that prevents their use with objects. Ergo, there is an existing syntax that solves the issue. In fact there are multiple. 9. I have not prepared RFCs for bundled Complex Number, Matrix, etc. types because those are just the use cases that brought me to this feature, not the only ones I have encountered, and I don't think that special-casing an internal class for every single one is a sustainable solution. How long before we end up with a Currency class also? Or a Length, Area, and Volume class that all understand how to multiply and divide into each other? What about other measurement units getting their own? I think that same thought process would also work against the idea of a Complex Number of Matrix class, and frankly, something like a Complex Number class is HIGHLY specific and would be virtually unused. I might have a use for it, but including it in the language is fairly dubious. Almost everything you have said are things that I have talked about or been asked about for years. That is why I have been fairly dismissive about them so far, not because I disagree. I am well familiar with these discussions, and I was hoping to get new feedback and thoughts through this thread. To hear specifics. The specifics I hear from you is something along the lines of "as long as you give me a way to force all my code, even code other developers wrote, to ignore this feature, I am fine with it". That's not really a helpful position at all, even if it IS a valid one. Jordan
