Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108991
To: "Christoph M. Becker" <cmbecker69@gmx.de>,
 Nikita Popov <nikita.ppv@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>
 <3ac8a6c1-a4e2-ecc9-053d-1c1a955a0325@gmx.de>
Message-ID: <de541067-a355-cca0-eddb-65a4c8979cd7@gmx.de>
Date: Thu, 12 Mar 2020 09:31:38 +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: <3ac8a6c1-a4e2-ecc9-053d-1c1a955a0325@gmx.de>
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 11.03.2020 at 10:50, Christoph M. Becker wrote:
> 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> w=
rote:
>>
>>> 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 sta=
tic
>>>>> function __add(Vector3 $lhs, int $rhs)), the function handler is not=
 called
>>>>> if the operand types do not match the signature, and the other opera=
nd'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 w=
ould
>>>> perform dispatching based on the method signature, even if in this ca=
se
>>>> it's not a choice between multiple methods on the same class, but rat=
her
>>>> multiple methods on different classes. Some of the usual problems of =
method
>>>> overloading don't apply here (in particular, one could make a reasona=
ble
>>>> argument that the method on the first object should be chosen, even i=
f
>>>> there is a more specific signature available on the second object), b=
ut 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 =
my
>>> opinion this mechanism makes it a bit easier to use operator overloadi=
ng 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 doe=
s not
>>> support the given types. If you (the internals developers) says that t=
his
>>> 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

I have thought about this the last days, and I agree with you. Therefore
I have removed this feature from the RFC.

If PHP perhaps gets real function overloading someday, we could consider
then to integrate operator overloading like in other languages (a
separate handler for each type combination), which would be much more
useful than the mechanism I had proposed.

If there are no other open discussion points, I would put the RFC to
voting in the next days.


Thank you for your feedback,

Jan