Re: [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 17/09/2024 21:37, Rob Landers wrote:

I would prefer to see something simple, and easy to reason about. We can abuse some mathematical properties to result in something quite simple: 1. If both are scalar, use existing logic. 2. If one is scalar and the other is not, use existing logic. 3. If one is scalar and the other overrides the operation, rearrange

    the operation per its communitive rules so the object is on the
    left. $scalar + $obj == $obj + $scalar; $scalar - $obj == -$obj +
    $scalar, -($obj - $scalar). It is generally accepted (IIRC) that
    when scalars are involved, we don’t need to be concerned with
    non-abelion groups.

4. If both are objects, use the one on the left.

Step 3 requires operators to be overloaded in groups: the rearrangement of the binary "-" operator requires definitions of both the unary "-" operator and the binary "+" operator; and definitions that meet the appropriate mathematical rules. IMO, that's a lot more complicated than calling the "+" overload with an OperandPosition::RightSide flag; or Python's approach of separate "add" and "reflected add" magic methods. Since you mentioned Scala, I looked it up, and it seems to be on the other end of the spectrum: operators are just methods, with no mathematical meaning or special dispatch behaviour. In fact, "a plus b" is just another way of writing "a.plus(b)", so "a + b" is just a way of writing "a.+(b)" Maybe it would be "useful enough" to just restrict to left-hand side: 1. If the left operand is an object which implements the specified operator, call that implementation with the right operand as argument 2. Else, proceed as current PHP. This is where gathering a good catalogue of use cases would come in handy: which of them would be impossible, or annoyingly difficult, with a more restrictive resolution method? Regards, -- Rowan Tommins [IMSoP]