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

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:

# 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.


Reply via email to