On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings <andr...@dqxtech.net> wrote:
> To me it is not surprising that an RFC like this would be controversial. > We could enter a wonderful new era of value objects with operators, > but it is hard to envision that beforehand. > > The best might be to find and advertise with use cases and examples > from other languages. > (as mentioned, I don't really know where to start looking, otherwise I > would have already shared something) > Oh, this was always going to be a controversial RFC. :) Operator overloading is controversial in most languages, even the ones that have it and don't really have problems because of it. It's the kind of feature that doesn't affect most people most of the time, but that all developers end up having a strong opinion about one way or another. I talked about that a little bit in the internals podcast episode I did with Derick. NumPy is probably the absolute best example of this feature being used. NumPy is an absolute killer feature of Python, and drives an enormous amount of the development being done in the language. It could easily be pointed out that NumPy is the equivalent of an extension however, being compiled down and directly hooking into the Python language. NumPy is also not included in the core Python language, though operator overloading *is*, importantly. However, the toolchain for adding NumPy is much easier and consistent than the toolchain for PHP extensions in general, and NumPy didn't have to add overloads themselves as part of the extension (or teach Python devs the rules around using them in general). So as another example, I'll pull up the math libraries in PHP. I maintain a math library myself, but it isn't nearly as widely used as the works by Mark Baker. The mathematical uses have been described here as "niche" and "small". First let's see what Mark has to say about operator overloading (and this RFC specifically): > Likewise, I have libraries for Matrix and Complex Numbers, where this would be an incredibly useful addition.... a similar RFC using magic was proposed 6 years ago, and sadly never made it :-( I hope this time it is accepted, especially as a new keyword feels better than magic - Source: https://twitter.com/Mark_Baker/status/1477957056464359427 The libraries that Mark is referring to, markbaker/matrix and markbaker/complex, have over 105 million installs combined on packagist. (Source: https://packagist.org/?query=markbaker ) > And so would `$lineValue = $unitPrice * $quantity;` work fine, with less words to read... and people who don't understand operator precedence would have problems with more complex mathematical formulae whether it was operator overloading or method name - Source: https://twitter.com/Mark_Baker/status/1478137583989309440 > But why shouldn't it be `==`... these are valid use cases for a comparison; equally, vector additions ($vector1 + $vector2) are quite commonplace in mathematics - Source: https://twitter.com/Mark_Baker/status/1478131480383606787 Marco's response to the person who maintains the literal largest complex mathematics library in the entire language was: > Yeah, so use matlab? This is what I'm struggling with. I am seeing a lot of things here that sound an awful lot like "that's not *my* use case, so no". That isn't how you design the language. Nikita's objection to the syntax is much easier for me to understand, because it is based on *language design*. Mathematics isn't something that is never used or never needed in PHP. The idea that I need to justify this statement is somewhat alarming. I have provided not only a multitude of examples of use cases in the RFC, but I have repeatedly done so on this list as well. I have provided examples in mathematics and examples in other domains, such as with Collections, with userland scalar objects. I've mentioned possible future scope to expand further into things like better support for query builders. I do not believe the reason people vote no for this RFC is because they haven't been shown any use cases. The use cases are self-apparent and have *also* been provided, both within the current PHP ecosystem and outside of it. Both with existing extensions and userland libraries. I sincerely hope that the reason someone votes no on this RFC isn't because they think use cases don't exist or because the use cases are fringe. I also hope that it's not because of "abuse", as this is a boogeyman that is not supported by the ecosystems of nearly all languages with this feature. The problem is that without those two objections, I'm left with few reasons I could see to vote no, perhaps the most prominent being the one Nikita raised with finding the syntax objectionable. The syntax offers a lot for future scope in my opinion, some of it not even related to operator overloads. It provides us a better way forward for allowing objects to control casting, for instance. Many find the __toString() implementation to be lacking. Controlled casting in C++ for example however is accomplished with something like `operator (int): int`. Another suggestion that came through from the community after voting opened was to use something like `symmetric operator` to show that an operator can be in either position. It also could provide us with some way forward on improving/deprecating ArrayAccess. Burden on static analysis tools perhaps? But there are features that are difficult on static analysis that have been accepted. (Enums comes to mind.) If anyone is voting no truly because they are concerned that there aren't use cases to justify it, I'd like to hear that and what sort of examples they are looking for, because I feel I have done this multiple times on this list at this point. Jordan
