On Tue, 4 Jan 2022 at 03:23, Jordan LeDoux <jordan.led...@gmail.com> wrote: > > > > 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 fully agree: Any language should aim at doing math well, natively. You should not have to want to go to another language for calculations. If this is the case, the language is incomplete. And I think modern PHP aims to be or become a "complete" language. If people currently don't use the language for math problems, this says more about the language than about the people. There is a potential here to enable new packages that solve new problems, that people would have done in another language in the past. > > 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. > [..] That was me :) I suppose you are going to reply directly to that message. > [..] 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. Tbh, I had to warm up to the idea myself. At first I only thought of all the potential problems that were already mentioned here. The main problem was I only thought of existing code, not of new code to solve new problems. -- Andreas > > Jordan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
