On Mon, Aug 9, 2021 at 2:32 PM Mike Schinkel <m...@newclarity.net> wrote:
> 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. > > They are deterministic for given *values* and *types*. They are not deterministic over the whole category. > > 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. > > I have the stub RFC on github: https://github.com/JordanRL/operator-overloading-rfc However your suggestion is an excellent one. I will add some interfaces and abstract classes to that repository when I am able to illustrate what user implementations (or the PHP expressions of the C implementations) might look like. > > 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? > > I mean that it would need to be a complex number literal or object that fully understood its relationship to other literals and to the operators. The interfaces, if you ignore typing, would be similar to other number classes, but the *implementations* would be very different. That's the biggest problem with providing say a single abstract number class that has built in operator overloading. Unless it can then be extended and overridden, in which case it seems that it will result in much more heinous misusage to me than simply doing generic operator overloading. > > 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? > > Yes you're correct. The values of both representations are computed when changed in my own ComplexNumber class, and the most advantageous one in terms of algorithmic complexity is used for calculation in any given method. > > 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. > > The overloaded operators don't interfere with anything *at all* unless you use an object that has them defined, even if you use the extensions. The GMP operator overloads don't affect anyone unless they are using GMP. These will be the same, in that the operators are unaffected unless a class opts in to using the feature. > > We have differing opinions on that, so we should agree to disagree on that > subjective assessment. > > Alright. > 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 > > The identity comparisons (`===` and `!==`) were two comparisons that I specifically planned to exclude from this RFC. > > 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. > > And I wouldn't expect it to be clear at this point. I was reaching out now more to gather a list of preferences and concerns for the feature. Perhaps the best way to think about what I was looking for was the answers to these questions: 1. If anyone planned to vote against such an RFC regardless of implementation, details, or need, why? Could I understand what those concerns are. 2. Supposing that the feature were guaranteed for inclusion, what are the preferences of the people on this list for limitations, implementation details, and structure. 3. If anyone with deeper knowledge of the PHP source had some pointers for me on auxiliary things that would need to be changed with this RFC, I was hoping they would be mentioned. (For instance, I'm aware of DateTime's overrides and did not plan on converting them to extendible generic overrides.) > > 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. > Yes, I have the stubs of that work outlined in the RFC github I linked, and I will put some effort in over the next week to create some mock classes and interfaces to illustrate the use cases. Jordan
