Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108999
To: rowan.collins@gmail.com
Cc: PHP internals <internals@lists.php.net>
References: <005101d5edae$7b7c3e10$7274ba30$@gmx.de>
 <CAF+90c8RmtGaa_KfptNMP0yQ6_xRWJ_z_zPj5JU45E2+qoE0Dw@mail.gmail.com>
 <8776962f-71ac-0ee3-a1b8-42eb2926eef0@gmx.de>
 <CAF+90c-CQ=sGY-vRdAHRwwE9X1q5fRpX1VCOeZw-JRi5weRu0Q@mail.gmail.com>
Message-ID: <849f81ee-40e3-999d-a8b5-2701af2ec483@gmx.de>
Date: Fri, 13 Mar 2020 12:05:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-CQ=sGY-vRdAHRwwE9X1q5fRpX1VCOeZw-JRi5weRu0Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] Userspace operator overloading
From: jan.h.boehmer@gmx.de (=?UTF-8?Q?Jan_B=c3=b6hmer?=)

On Thu, 12 Mar 2020 at 10:06, rowan.collins@gmail.com wrote:
> On Thu, 12 Mar 2020 at 08:31, Jan B=C3=B6hmer <jan.h.boehmer@gmx.de> wro=
te:
>
>> On 11.03.2020 at 10:50, Christoph M. Becker wrote:
>> > On 11.03.2020 at 10:22, Nikita Popov wrote:
>> >> Does anyone else have thoughts on the ability to specify the support=
ed
>> >> types in the signature?
>> > I agree that we should not introduce (this special case of) overloade=
d
>> > functions.
>>
>> I have thought about this the last days, and I agree with you. Therefor=
e
>> I have removed this feature from the RFC.
>>
>
>
> I've been thinking about it as well, and am not sure what happens _witho=
ut_
> it in a case like this:
>
> # initial class, only overloads + on instances of itself
> class A {
>    public static function __add(A $lhs, A $rhs) {
>         // ...
>    }
> }
>
> # in some third-party library
> class B {
>    public static function __add(A|B $lhs, A|B $rhs) {
>         // ...
>    }
> }
>
> $a =3D3D new A;
> $b =3D3D 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
>
> If the engine doesn't catch the TypeError, it will never try B::__add($a=
,
> $b) in the second case, so presumably the TypeError will just be thrown =
to
> the user, which doesn't seem very helpful.
>
> Perhaps the simplest solution is to have a restriction that the operator
> overloads _must not_ specify types in their signature?
>
> Regards,
>
> Rowan Tommins

I have implmented your suggestion. If an operator handler has typehints, a=
n error will be thrown,
similar to the behavior if they would not have the required amount of argu=
ments or were not static.
The restriction that some functions can not declare typehints is not compl=
etly new, e.g. constructor must not declare a RETURN typehint,
so I think it is not completly inappropriate to prevent your mentioned pro=
blems this way and I will most likely add this to the RFC.

What do others think about this restriction?

Furthermore I added a check that no arguments are passed by reference (lik=
e with other magic methods). We can not really prevent that a user manipul=
ates passed objects (as they are always references),
but at least for builtin values (int, string, etc.) it should not possible=
 to modify their source. Also this would lead to problems, as the 1 in som=
ething like $a + 1 can not be passed as reference.

Regards,
Jan B=C3=B6hmer