Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115648
MIME-Version: 1.0
Date: Fri, 6 Aug 2021 09:34:02 -0700
Message-ID: <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003286f605c8e69a38"
Subject: Revisiting Userland Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000003286f605c8e69a38
Content-Type: text/plain; charset="UTF-8"

Hey all,

I contacted Jan a few days ago to ask if they were going to try again for
their RFC, but I wanted to get a quick temperature check on this.

I would like to work on this RFC for 8.2, and after going through previous
discussions on the topic, I feel like the right place to start is to limit
the RFC to only the mathematical operators at first.

Based on previous comments, I was considering working from Jan's previous
implementation with these basic changes:

1. The only supported operators in the RFC will be the mathematical
operators: (+, -, /, *, **, %)
2. The RFC would also provide an interface, (something like
MathObjectInterface), that has all the magic methods in it.
3. The do_operation would be changed to check for the interface being
implemented instead of the specific method.

All of these operators belong to the same "group" of changes, and (broadly)
any object that is valid to override for one of them should be valid to
override for any of them. NOTE: There are edge cases of this statement
certainly.

This would help address some of the concerns that were expressed about
misuse of things like the + operator to add things to a cache. It would
more explicitly take a position on how these operators should be used in
userland code to keep them more consistent with the behavior of these
operators in normal PHP code.

This would be my first contribution and my first RFC, so I wanted to get
some very broad feedback on this before diving in.

It would suggest that future sets of operators could come with their own
interfaces to also attempt to guarantee an all-or-nothing approach in
userland code, (BitwiseObjectInterface, ComparableObjectInterface,
LogicalObjectInterface, etc.). Though decisions on any of those operators
or their implementations would be left as future scope.

Jordan

--0000000000003286f605c8e69a38--