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
