Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109579
MIME-Version: 1.0
References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de> <7a83f950a31d94d5ff2307ac8219db3b7b6482b6.camel@schlueters.de>
 <CANZOY=Cre6iCUskSWoic1D22s197b553i+tp5hBK_iuiFo_=cA@mail.gmail.com>
 <12ad7c71-8958-7742-12c4-e83e359c8186@gmx.de> <3B71F74D-8142-48FB-9660-835B08D1DDDD@schlueters.de>
 <705aba69-8c17-f882-19fd-6f41a2c2ca25@gmx.de> <07f176a5c2ff0338cb67c9755bf37af6dcc2d465.camel@schlueters.de>
 <CAF+90c_w=igQi3skmiOKeJ+t=BjRTmM-7u=-SOpj_ri+gxZ08Q@mail.gmail.com>
 <BD01F8AF-C8EA-4F41-9208-0F4169886AA2@schlueters.de> <000d01d60c4a$a213fb20$e63bf160$@gmx.de>
In-Reply-To: <000d01d60c4a$a213fb20$e63bf160$@gmx.de>
Date: Thu, 9 Apr 2020 13:18:27 +0100
Message-ID: <CA+kxMuSw6OkXqyWUyivOxkeunJD_G62xRX1p6zsmrammXkpTHw@mail.gmail.com>
To: jan.h.boehmer@gmx.de
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Userspace operator overloading
From: Danack@basereality.com (Dan Ackroyd)

On Mon, 6 Apr 2020 at 20:36, <jan.h.boehmer@gmx.de> wrote:
>
> Hi internals,
>
> I have closed the voting. With 38 in favor and 28 against the RFC is DECL=
INED (didn=E2=80=99t reach the needed 2/3 majority for a new feature).
>
> Thanks to everyone who has participated.
>

Hi Jan,

Thanks for running the RFC. Although it didn't quite pass it seems a
lot closer now.

Apologies for not taking part in the discussion earlier, but I'm slow
at thinking. To follow up on a couple of things.

> If it can not handle the given type, it has to return the
> constant PHP_OPERAND_TYPES_NOT_SUPPORTED (currently just null).

This does not appear to be a good choice. It means that to evaluate
whether the code is safe to call the code needs to be evaluated. That
makes doing static code analysis very difficult.

Also, it means that operators could not return null as a result of the
operation, which seems like an odd choice that would be a regretful
limitation.

Rowan Tommins wrote from https://externals.io/message/108788#108993 :
>
>
> $a =3D new A;
> $b =3D 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

And jan.h.boehmer@gmx.de wrote:
>
> If an operator handler has typehints, an error will be thrown,
> What do others think about this restriction?

I think that is the wrong solution to the wrong problem.

It's a wrong solution because parameter types* are a useful tool both
for program correctness at runtime, they make it easier to run static
code analysis tools on the code and most importantly they save a lot
of developer time, mostly through autocomplete.

It's the wrong problem because 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 $lhs, A $rhs) {...}
}

class B {
    public function add(A|B $lhs, A|B $rhs) {...}
}

$a =3D new A;
$b =3D new B;

$b->add($a);  // Ok
$a->add($b);  // TypeError
```

For me, the solution to the error in this code is not "remove the
parameter type on A::add". I'm pretty sure that the solution to this
type of error would be "fix your code".

When someone looks at the idea of userspace operator overloading
again, I think the following path might reach a more acceptable
solution.

* Encourage people to use parameter types to make their code easier to
reason about.

* Encourage people to use static analysis to check their code for
errors, including errors where they have invalid operands to
operations.

* Take the approach in the RFC that passing a wrong parameter type to
an operator magic method represents a programming error that cannot be
handled in the normal program flow, and that throwing an exception is
the right thing to do here**. But as most people should be using
parameter types, and static analyzers to check for this type of error,
this should not occur.

Other than a learned reticence against throwing exceptions, what
downsides would that have?

cheers
Dan
Ack


* PHP has parameter types that are checked at runtime, not 'hints'
that can be worked around as found in other programming languages. If
people would stop using the phrase 'type hint', it would make the
conversation more accurate.

** This is not using exceptions for flow control (though it could be
abused for it). Most people should be avoiding these problems through
writing code correctly, and using static analysis to double-check
their code is free from errors.