Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116947
MIME-Version: 1.0
Date: Fri, 28 Jan 2022 15:11:40 -0800
Message-ID: <CAMrTa2FMC+zPKwMt94JmMMP-E9TWcQCYXmXGbX1wQsimYG2oiQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005df6b705d6ac8f86"
Subject: Handler(s) and priority for == and != opcodes
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000005df6b705d6ac8f86
Content-Type: text/plain; charset="UTF-8"

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

--0000000000005df6b705d6ac8f86--