Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115649
User-Agent: Cyrus-JMAP/3.5.0-alpha0-552-g2afffd2709-fm-20210805.001-g2afffd27
Mime-Version: 1.0
Message-ID: <f0732667-5cd6-4419-97df-7a9bd30684ce@www.fastmail.com>
In-Reply-To: 
 <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
References: 
 <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
Date: Fri, 06 Aug 2021 12:49:00 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Aug 6, 2021, at 11:34 AM, Jordan LeDoux wrote:
> 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

If you wanted to cluster them, I would strongly recommend much smaller groupings.  IMO, adding two collections to get another collection -- like we add/merge arrays -- is a completely reasonable thing to do, but would only use + and potentially - (for removing items from a collection and returning the smaller collection). But * and / make no sense in that context.

Even if you confine yourself to mathematical concepts, matrix multiplication is a well-established thing that would make sense for math-centric applications to do.  But matrix division is... somewhat more fiddly, and has multiple possible definitions.  (Note: I've not done matrix math in over 20 years, so I'm basing that statement on some quick googling.)

So I don't think force-grouping the overloads makes sense, in practice.  I'm still open to operator overloading in general, but I don't think the clustering is going to help.  The weird and complicated type interactions, particularly when it comes to commutablity, are a much larger issue, IMO.

--Larry Garfield