On Thu, Apr 9, 2020, at 10:05 AM, Rowan Tommins wrote:
> On Thu, 9 Apr 2020 at 13:18 (and subsequent correction), Dan Ackroyd <
> dan...@basereality.com> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
