Hello internals,
Following the rejection of the operator overloads RFC I have looked at
bringing some mathematical improvements to PHP in extensions instead. As
part of this, there is one truly blocking issue:
The opcodes for == and != are handled by the compare handler.
On zend_class_entry, extensions can define a handler for do_operation which
allows them to overload operators. As I described in the op overloads RFC,
this is something that extensions and C code can fully accomplish, it's
just restricted for userland code.
However, currently the following operators are handled by the compare
handler instead:
, >=, ==, !=, <=, <, <=>, <>
The reason this is a problem is that in mathematics (and presumably other
domains), it is possible for something to be equatable but not
sortable. For example, consider the following:
2 + 1i == 2 + 1i
This should return true. However:
2 + 1i >= 2 + 1i
This should either return false or throw an exception or error.
Complex numbers are not comparable, but they can be equal or not equal.
To accomplish this, the zend_class_entry handlers must provide a way for
the ==, !=, and <> opcodes to be handled separately if desired.
I discussed this issue briefly with nikic, joe, and cmb. Both nikic and cmb
expressed understanding of the issue and a tentative understanding of the
value of this change, while joe didn't provide any negative feedback.
I'd like to alter the VM and possibly zend_class_entry in order to
accomplish this. This can be done in a BC compliant way, meaning that it's
an internal engine change that doesn't require an RFC.
However chris brought up the point that this could be accomplished by
either sending the relevant opcodes to the do_operation handler or to a
brand new handler.
The PR for the first option (sending it to do_operation) can be viewed
here: https://github.com/php/php-src/pull/7973
I'd like to gather feedback on whether it's more appropriate to send this
to the do_operation handler or to create a new handler.
Jordan