On Thu, 9 Apr 2020 at 13:18 (and subsequent correction), Dan Ackroyd <

[email protected]> wrote: $a = new A;

$b = new B;

var_dump($b + $a); # calls B::__add($b, $a); OK

var_dump($a + $b); # calls A::__add($a, $b), which is a TypeError ... that code does have a TypeError. It is

calling '__add' and passing a parameter to the method that the code

can't handle. It appears to be the same error case as: class A { public function add(A $rhs) {...} } class B { public function add(A|B $rhs) {...} } $a = new A; $b = new B; $b->add($a); // Ok $a->add($b); // TypeError As with so much else on this topic, it depends how you think about operator

overloading - and I think that's why it's so hard to agree on an

implementation. It seems that you're picturing the overloaded + as like a normal method but

with special syntax, so that $a + $b means the same as $a->add($b) and only

that. In that interpretation, it's perfectly reasonable to have the

operation succeed or fail based only on the left-hand operand, because

that's how we're used to method dispatch working. But if you look at how "normal" operators work, it's far less obvious that

the order of operands should play any role in that decision. For instance,

when mixing float and int, the result is a float if either of the

operands is a float: var_dump(1 + 1); # int(2)

var_dump(1 + 1.0); # float(2)

var_dump(1.0 + 1); # float(2)

var_dump(1.0 + 1.0); # float(2) Substitute 1 for $a and 1.0 for $b, and you're back to the example I

originally wrote. Note that this is true even for non-commutative operators

like exponentiation: var_dump(2 ** 3); # int(8)

var_dump(2 ** 3.0); # float(8)

var_dump(2.0 ** 3); # float(8)

var_dump(2.0 ** 3.0); # float(8) My impression is what people consider "good" use of operator overloading is

much closer to "make things act like built in numerics" than "make

operators with fancy syntax", so some form of symmetry is necessary I think. Regards, Rowan Tommins

[IMSoP]

Idle, possibly naive thought:

When applying operator overloading to objects, perhaps we could simplify matters by insisting that it only work for directly compatible types? That is:

class Foo {

public function __add(Foo $b): Foo {

return new FooOrChildOfFood();

}

}

It would work for interfaces too, but the point is that you can't operate on just any old other value... only one that is of the same type.

You could technically have a BarInterface, and then only the left-side object gets called, but it means it has to be combining two BarInterface objects, which means it knows how, because BarInterface has the necessary methods. If not, then your BarInterface is wrong and you should feel bad.

This creates a narrower use case, but perhaps one that still fits the practical usage patterns? (Eg, adding Money objects together, etc.)

If an operator by design wants different types on each side (not for numeric behavior, but for, eg, a function concatenation operator), then you would have to type the RHS you expect (eg, a callable in that case).

It's not as extensible, but the extensibility seems like it's the problem in the first place. I generally agree with those who have said that any such functionality needs to leverage the type system effectively, not side-step it.

As I said, possibly naive thought, but could deliberately reducing the scope make life simpler?

--Larry Garfield