Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108969
To: Nikita Popov <nikita.ppv@gmail.com>, =?UTF-8?Q?Jan_B=c3=b6hmer?=
 <jan.h.boehmer@gmx.de>
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: <3ac8a6c1-a4e2-ecc9-053d-1c1a955a0325@gmx.de>
Date: Wed, 11 Mar 2020 10:50:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-CQ=sGY-vRdAHRwwE9X1q5fRpX1VCOeZw-JRi5weRu0Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] Userspace operator overloading
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 11.03.2020 at 10:22, Nikita Popov wrote:

> On Fri, Mar 6, 2020 at 9:17 AM Jan B=C3=B6hmer <jan.h.boehmer@gmx.de> wr=
ote:
>
>> Am 02.03.2020 um 15:30 schrieb Nikita Popov:
>>
>>> On Thu, Feb 27, 2020 at 9:43 PM <jan.h.boehmer@gmx.de> wrote:
>>>
>>>> If the operator handler function declares typehints (e.g. public stat=
ic
>>>> function __add(Vector3 $lhs, int $rhs)), the function handler is not =
called
>>>> if the operand types do not match the signature, and the other operan=
d's
>>>> handler is tried to call.
>>>
>>> I'm somewhat skeptical about this. This smells of method overloading, =
and
>>> we don't do method overloading. There is no other place in PHP that wo=
uld
>>> perform dispatching based on the method signature, even if in this cas=
e
>>> it's not a choice between multiple methods on the same class, but rath=
er
>>> multiple methods on different classes. Some of the usual problems of m=
ethod
>>> overloading don't apply here (in particular, one could make a reasonab=
le
>>> argument that the method on the first object should be chosen, even if
>>> there is a more specific signature available on the second object), bu=
t I'm
>>> skeptical about introducing this kind of special case in the language
>>> specification.
>>
>> Your point about the "smell of method overloading" is interesting. In m=
y
>> opinion this mechanism makes it a bit easier to use operator overloadin=
g as
>> you dont have to do tedious typecheckings on your own in simple cases. =
But
>> I agree that this behavior is a bit odd compared to other PHP features.
>>
>> That feature is not really needed for operator overloading, as you can =
use
>> the PHP_UNKNOWN_OPERAND_TYPES const for signaling that the handler does=
 not
>> support the given types. If you (the internals developers) says that th=
is
>> does not fit into the concept of PHP, I will remove it from my RFC (or =
put
>> it in a separate votation, if wished).
>
> Does anyone else have thoughts on the ability to specify the supported
> types in the signature?

I agree that we should not introduce (this special case of) overloaded
functions.

Thanks,
Christoph