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. # Non-Breaking Engine Changes The way that equality and comparison evaluation is done in the engine makes it impossible for certain kinds of overloading to be done, even in extensions. This isn't because that was an intended restriction, I discussed this issue with CMB and provided a PR a few months ago to resolve this, however it has remained in limbo: https://github.com/php/php-src/pull/7973 # Overall Vision I'm not sure at this point how voters think objects and operators should work together into the future. I'd like to see if anyone is willing to have high-level discussion about the ideas, instead of picking at the implementation or details of a particular RFC. Jordan
