On Aug 9, 2021, at 5:32 PM, Mike Schinkel <m...@newclarity.net> wrote:
> On Aug 9, 2021, at 1:48 PM, Jordan LeDoux <jordan.led...@gmail.com> wrote: > 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.* Improving documentation is an easier fix than adding a complex language feature. And a key difference is (almost?) anyone who is motivated can contribute to the docs; not so for adding language features. For example, why is it not an option for you to update the docs for DateTime and DateInterval if the docs are bad? Or other classes that have could have operator overloading in the future? > 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. So are you arguing that PHP should have no library functionality and have everything implemented in PHP? I don't mean to commit a reductio ad absurdum, but I am honestly confused by your need to see the implementation of behavior in PHP that is well-known and well-established in science and business. I honestly don't get why it would be important to see the internals of DateTime and DateInterval class, or a ComplexNumber or a Money class for that matter. Why can't that just be documented, other than your claim that "docs are bad?" Why it will be important to see operator overloading implementations in PHP when you don't see sin() and cos(), for example? This really feels like a personal preference and not a driving need for everyone. But if others agree that seeing operator overloading in PHP code is critical, please do speak up and, for my edification, please do explain why. > 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. Yeah, I don't see this as a problem. Internally if there are a lot of similarities than the similarities can be shared by a common function. Duplication is not a problem in an of itself. If you only have to write it once and rarely ever need to maintain it. > 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. That is in part of why I asked for use-case examples, to see if there really were a lot of use-cases where operator overloading makes sense. You only provided two categories; Math and the already existing DateInterval. It's not like operator overloading is a feature which without developers literally cannot implement functionality. Even though you (currently) cannot compose an expression of objects like `$cn1 + $cn2` doesn't keep you from implementing `$cn1.add($cn2)`. Let us assume that because we were to create operator overloads for DateTime and DateInterval and for your Math needs people started inundating the list with requests to add hundreds of other classes (I really doubt that would happen, but I'm running with it anyway.) One easy answer is for the list to come up with a checklist for operator overloading concerns and request those asking to present userland libraries that would want operator overloading and show how the libraries would address the concerns in the checklist. Once done, then the list could review and make a decision. OR, *if* the list really is inundated with requests, maybe we *then* realize there are many use-cases, and we move towards a generic operator overloading. But as of today I am not convinced that there are really that many use-cases for operator overloading that would not just be a leaky abstraction. (As an aside, how are we going to implement operator overloading in DateTime and DateInterval within PHP? Do we have to subclass just to get them to have operators? So minimally, we should start with those two and write it in C for PHP core.) >> https://medium.com/@rwxrob/operator-overloading-is-evil-8052a8ae6c3a > 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. The one and only comment expresses the commenter's opinion, not "why it's incorrect." You dismiss the author's points you disagree even though he wrote a full post that also references why the Go language designers choose to avoid operator overloading but you attribute much greater authority to the drive-by commenter who simply states an opinion you agree with. When it boils down to it, it's all just opinion. I included his link because you strong implied that nobody has issues with operator overloading in Python while that post illustrates that some people do have issues with operator overloading in Python. > 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. Different languages have different selling points. The features needed to make Python a really good maths language are not the same features that are needed for building robust, reliable, and maintainable web applications. And features that make a language good for one use-case can make it less good for another, which is what I especially believe about operator overloading. Operator overloading is useful for languages that are intended for implementing DSLs. Open question: do we collectively want PHP to be able to be a strong language for writing DSLs? (If yes, I have a slew of features I'll be asking for.) Honest question: If Python is so much better for math and you appear to be a math guy, why are you using PHP? What are your use-cases where you can't just use Python? > 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(). They are both syntax sugar for calling methods. And they are both methods userland developers may not have the time or the expertise to handle properly. And I am not talking down to userland developers; *I* do not have the expertise to address the issues in a maths library. > 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. However, you are actually making my point, which is that since they are so deterministic then why is there the need for flexibility to be done in userland vs. the standardization that could be could be better in PHP core? For the latter we can ensure the abstractions are not leaky and the requirements are fully addressed. > 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. That seems a rather thin justification for adding a complex language feature which we could potentially wish we had not. Anyway, you can always stick around to champion their needs. > 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. Why don't we start with this? Rather than initially focus on the syntax for creating operator overloading why don't we start by focusing on the known use-cases and come up with documentation showing how those use-cases would leverage the custom operators? Fully map them out. If we do that and we still get general operator overloading then at least userland will have a roadmap for how to get started with operator overloading for the known use-cases rather than lots of developers seeing a shiny new feature that they all start adding to their code, badly. You can easily create this doc on GitHub and solicit PRs from others far and wide for their use-cases. > 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. We have some operators, but not all the useful ones. > 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. It would help me if we could discuss this in specific terms rather than abstract terms. What does "fully-featured complex number library" mean? Can you create a Gist showing what the class interfaces would look like in PHP code? > 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. Correct me as I may be wrong, but isn't int+imaginary a function of (r, theta) and vice-versa? If yes, I assume that both representations could be generated by the same ComplexNumber class? > 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. The custom operator overloads in C require a lot more skill and experience to implement than in PHP which I am arguing is a benefit related to operator overloading. Further, only people who are not using managed hosting that constrains the extensions used are able to use these extensions. So these overloaded operators are not infecting PHP code far and wide. > 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. This seem to me to be the perfect example of how to move forward with a Maths library. > 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. > > 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. We have differing opinions on that, so we should agree to disagree on that subjective assessment. > DateTime already has overloads for comparison operators and has for a long > time. stdClass objects also support equals comparison so really this is more about add, subtract operators which DateTime and TimeInterval do not have. Which brings up this question: If we allow comparison operator overloading for objects does that DateTime comparisons might no longer mean they are the same pointer but instead a userland comparison? If yes, that actually chills me to the bone. https://3v4l.org/2RCot#v8.0.9 > 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). Exactly. More of Nikita's approach is what I am advocating for. > 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. That's absolutely fine and understood. That's the way it works for PHP. Similarly I will advocate others consider fleshing out specific use-cases and ideally have us implement a few before we consider adding generic operator overloading to PHP. Unless of course I find that there is a strong consensus to move forward with generic operator overloading in which case I will demure. But thus far it is not clear which way that wind actually blows. > "why is this use case given preferential treatment?" and I will be unable to > answer because I would raise the same objection myself. My answer would be "Because there is someone championing this use-case and not for other use-cases." #fwiw. Given our dialog, maybe we can meet half-way? Since it's a year out as you say, why not go ahead and start documenting the use-cases and how operators would be used for those use-cases? Like I said above, that work will need to be done by someone eventually if generic operator overloading is added; better to do it once and share than have each developer have to redo on their own. And I might even become more supportive if I can see that choices that need to be made regarding operator overloading are more obvious than I am currently assuming. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
