> On May 6, 2022, at 6:16 PM, Jordan LeDoux <jordan.led...@gmail.com> wrote: > > Hello all, > > I took a while away after my operator overload RFC was declined. I've been > mulling for the last few months how to move forward while respecting the > concerns and feedback of those who abstained and those who voted against. > But I feel like a separate discussion needs to happen first after > considering many different approaches. > > # There is Considerable Demand For Improved Control of Operators with > Objects > > This doesn't apply to all operators. I have not seen any comments in the > last few months of digging of people who are desperate for the pow operator > ( ** ) for instance. However, many people who work with math in PHP have > use for at least the arithmetic operators and I see this comment frequently. > > Totally separate from the math domain, I've seen many comments about the > desire to control the comparison operators: >, >=, ==, <=, <, !=, <>. This > is something that would have numerous applications outside of mathematics, > and there's even been an RFC worked on (that was declined in 2018) by Rudi > to implement just comparisons. > > # Different Voters Have Different Concerns > > This is an issue that almost all RFC authors must deal with of course, but > this particular subject suffers from it more severely than most. For > instance, in some of the past proposals that were more limited than mine, > there were comments that a full operator overloading solution should be > provided instead of something halfway. > > However one of the comments I received more than once was that I should > separate out the comparison operators into its own RFC, since those have > applications outside the math domain. > > # Is Math A Valid Use Case? > > One of the more shocking (to me personally) pieces of feedback that I > received from more than one person is that math is not a valid use case in > PHP. I am... unsure about what to think of this opinion. I guess I would > like to discuss and find out if this is widely believed among voters.
I will repeat what I suggested back before the RFC was voted on, and that is you consider *starting* your campaign for operator overloads with an RFC to add a built-in Math class (or set of classes) to PHP, one(s) that can have all the operator overloading it/they need(s). Minimally the design process in the open would be insightful for everyone interested in the topic even if the RFC did not get accepted — although the intent should be that it would — because it would change the operator overload discussion from a very abstract one to a very concrete one. It could also illustrate the benefit for operator overloading, and illustrate the design process of deciding on how operators are overloaded and what the benefits and tradeoffs are of different choices. If the RFC did not pass, at least it could result in an understanding of which operators minimally need to be overloaded for the Math use-case and serve as a blueprint for adding Math objects in userland if and when sufficient general-purpose operator overloading could get added to PHP. Further, if an RFC to add a built-in Math object to PHP passed it would effectively eliminate the red-herring of "I don't do heavy math work." Such an RFC would also, of course, not have the other two (2) categories of objections that you named in your other email. Again, #jmtcw -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
