Re: Revisiting Userland Operator Overloads

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