My recommendation is to have a base interface for every operator that can
be overloaded, so that these can be composed together.
AddOverloadInterface { __overloadAdd(): self; }
SubOverloadInterface { __overloadSub(): self; }
MulOverloadInterface { __overloadMul(): self; }
DivOverloadInterface { __overloadDiv(): self; }
ModOverloadInterface { __overloadMod(): self; }
LeftShiftOverloadInterface { __overloadLeftShift(): self; }
RightShiftOverloadInterface { __overloadRightShift(): self; }
XorOverloadInterface { __overloadXor(): self; }
etc.
Then if you were implementing matrix math, you could do this:
MatrixMath implements AddOverloadInterface, SubOverloadInterface,
MulOverloadInterface {
}
This prevents you from having to define methods for operations you don't
support.
It's probably worth exploring whether common combinations are worth
defining for convenience.
On Fri, Aug 6, 2021 at 1:49 PM Larry Garfield <la...@garfieldtech.com>
wrote:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
