On Mon, Aug 9, 2021 at 3:49 AM Mike Schinkel <m...@newclarity.net> wrote:
> 1. When you speak of "not documented in the code" do you mean the > implementation would not be in PHP code? Okay, yet none of these functions > are documented in PHP code and they are all available in PHP: > > https://www.php.net/manual/en/ref.math.php > > AFAIK few people who do not struggle with programming or math have any > problem with these functions, because they are all documented. > Yes, that is precisely what I mean. Operator overloading is a complex feature, I have never pretended otherwise. Having the behavior documented in the code base you are working on, in the code itself, is FAR more useful. My primary example of that is this: You claim that this would be documented on php.net and this would be sufficient. Yet the DateTime class has had operator overloads for comparison operators since 5.2 and there is still *zero* mention on php.net (that I am aware of or can find) of this. Not even a mention that it exists, let alone what the override behavior is. *Not even in the god-awful comments on the manual.* Simply put, as someone who has spent my entire career working primarily in PHP and been working in it since PHP 4, it has one of the very best free and online manuals for any language I've worked in, and I would still 10 times out of 10 prefer to be able to see the implementation in my IDE than have to look it up on php.net. > 2. Yes, it would require many different implementations, one for each > use-case. Unique logic has to be implemented. Somebody has to do it. Why is > that a problem? > > I am not sure what you mean by being "very close to each other to cover > the same set of use-cases" unless you are talking about many different > arbitrarily different userland implementations, which I doubt since that > would be a reason not do add operator overloading. > > What I mean is that there would be multiple "number like" abstract classes that would be 80% to 90% similar. That is, if it actually correctly represented the core math ideas. This method however would utterly fail for unit based value overloads, of which Rowan's money example is a specific case. > 3. Regarding maintainability concerns. Code generally doesn't rot unless > the requirements change. Are requirements going to change? If yes, then its > not a strong use-case for operator overloading, in core or userland. We > should guard against operators used for convenience that are leaky > abstractions. > > BTW nobody can "demand" new features in PHP and be effective. But if they > propose them in an RFC it helps ensure these new features are fully fleshed > out, to the best of the list's collective ability. > > Yes, I'm aware. :) The process that PHP employs with internals to maintain the language is one of its greatest strengths in my personal opinion. I shouldn't be able to simply open a PR and have the maintainer be the only one that looks at it. My RFC, whether it is accepted or not, will be better because of this process. It has already been improved by this thread. However, creating abstract classes simply for custom operator overloads would signal to users that this is something internals is willing to do. Despite the fact that I am confident the process would continue to work, I would very much anticipate multiple and continuous threads opened by users wondering when "their" operator overloads are going to be included. While this obviously doesn't force anything, it absolutely is a distraction. > While it is hard to objectively quantify how much is "much" this gentlemen > — a programming teacher — had some choice words to say about operator > overloading specifically related to Python: > > https://medium.com/@rwxrob/operator-overloading-is-evil-8052a8ae6c3a > > A pull quote from his blog post: > > "You wanna know what is not simple? Operator overloading. It has no place > in any language. It’s an aberration to be shunned." > > He feels even more strongly about the perils of userland operator > overloading than I do! > :/ I was hoping for something more concrete than what he said in this article, especially when the one and only comment on the article succinctly expresses why it's incorrect. Python's major "selling point" over other languages, especially for its initial adoption and wide use in teaching, is its power in scientific computing, and those libraries 100% *depend* on Python's operator overloading. > A while back someone proposed __ToArray and Rowan (among others) fought > back hard saying that the problem is that exporting an object to array > could mean different things to different people and there is often a need > to export to multiple different array format, and thus the use-case should > always be implemented as a named function. A first I was annoyed that the > list was pushing back because I wanted to use __ToArray, but the more I > thought about it the more I realized that Rowan and others were right. > > Overloaded operators are no different than a __ToArray method. What does > __add() really mean for most classes? > > Respectfully I disagree. There can be different meanings for __add() with different operands, just like `2 + 3` is different than `2.1 + 3.1`. But an operator heavily implies the idea that there is a single and deterministic result for a given set of input values and input types. I do not believe that these are at all similar to _toArray(). The fact that internals cannot anticipate what they are because the domains and context are varied is not the same as the results being non-deterministic or usage dependent. They are not arbitrary in the same way that array structure is. > I appreciate that you have anxiety that if you don't get it all now, you > never will. I understand that, I feel the same way about the things I'd > like to see added to PHP. > That's not exactly what my concern is, though I can also understand that concern. My concern is that I think I can properly advocate for and explain the use cases and implementations that would benefit my own work, but I do not know that others could be able to do so. > But I have also realized that pushing through a feature too quickly can > have far reaching consequences and a damaging outcome. Better to take > small steps and allow time for the features to mature than to dive in and > make a mistake and have to live with it for the rest of PHP's useful life. > This is why I'm targeting this for 8.2 and started this conversation nearly a full year before the feature freeze for 8.2. I am not going to come through with the RFC vote in a few weeks, this is going to be slow, deliberate, and inclusive, because that is the only sensible way that a change as complex and impactful as what I'm proposing could be done correctly. If we were to — for example — start by adding operators to DateTime and > DateInterval it would give us real-world experience with operators and > objects before we fully commit to adding operator overloading for all > classes. > > We could then take our learning for DateTime and DateInterval and add > another class, maybe ComplexNumber. > Heck, we might even recognize value in creating an imaginary number > literal to support it; that type of domain-specific value won't happen if > we just focus on generic operator overloading. > > Once we have ComplexNumber down, maybe we tackle a few more Math classes, > and many we even tackle Money. > This is interesting, since we *do* have operator overloads for DateTime already and have for quite a long while. This is covered briefly in the draft RFC I linked in my last message. An imaginary number literal couldn't really be supported without either a fully-featured complex number library in core (not just an abstract stub with operator overloading), or errors/exceptions on multiple operator combinations. For instance, `int + imaginary` would require some representation of complex number as a result type. This is, to my understanding, why this is usually left to userland implementations in most languages, particularly since complex numbers are advantageous to represent as `int + imaginary` in some circumstances and `(r, theta)` in other circumstances. > But one thing is certain. While we can go from special one-off classes > that support operator overloading to later adding general-purpose operator > overloading, we cannot go the opposite direction. That makes the idea of > first testing out operator overloading on specific use-cases a much less > risky proposition that just adding general purpose operator overloading > from the start. > This is a point that I obviously can't casually dismiss, because it's simply a fact. Once user defined operator overloading exists, it can't reasonably be undone, however it can always be added on top of abstract classes in the future. That being said, this is not something that internals hasn't considered before *and* there already are custom operator overloads in C implementations in PHP. There are also extensions that cover more domain specific C implementations, such as ext-decimal and ext-gmp. The first version of this feature that I'm aware of was worked on for 7.1. So while your point is valid and powerful, my contention isn't that you're wrong, but rather that now *is* later for this feature. Internals has looked at this feature before, nearly accepted it into core for 8.0, and provided a great deal of feedback and discussion on its benefits and problems. Multiple examples of it in PHP exist in C implementations. Arrays treat `+` as a union operator. Strings and arrays both work with `<=>` and execute some fairly complicated (and opinionated) logic to determine sort order of those types. DateTime already has overloads for comparison operators and has for a long time. Both ext-decimal and ext-gmp have implemented domain-specific operator overloads. In fact, the operator overloading for GMP done by Nikita for 5.6 covered much of the same arguments (though it obviously didn't include userland operator overloading). I am not dismissing your point here, but I'd like to respectfully suggest that we now have the information to address the topic, instead of needing further use cases to consider. Finally, as I mentioned I won't be entertaining that format for this RFC. While I have said that I understand the argument, I would suggest that those who feel it is a better alternative work on it as an RFC if they believe it is a better route. This RFC may take me the entire year and still get rejected, and I understand that. I would simply not be a good advocate for such an approach, because the very first objection is going to be "why is this use case given preferential treatment?" and I will be unable to answer because I would raise the same objection myself. Jordan
