Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110409
MIME-Version: 1.0
References: <CAP=4hCKgwc9_Q6NtVnHajc3HAsHATPvLH-MLAKSQP=m+xP2yEg@mail.gmail.com>
 <CAF+90c-S8xBwL04GgaS1dLQEEdeG4Kx2h7iYiJrstcEK22m9hg@mail.gmail.com>
 <CAP=4hCJg595KnHdgDv5m__RYqKnTCRyW+zJfJWR9hhY_+1b4-w@mail.gmail.com>
 <CAF+90c_0N1sBn-LjDxeRUbF6=0MT6kUCoDpd+gzm=8Vh445yUA@mail.gmail.com> <CAP=4hCLBYA0Zz0ak1VierbBBnkEt7J8Fhm2NgVujWL2jNArTag@mail.gmail.com>
In-Reply-To: <CAP=4hCLBYA0Zz0ak1VierbBBnkEt7J8Fhm2NgVujWL2jNArTag@mail.gmail.com>
Date: Sun, 7 Jun 2020 18:01:58 +0200
Message-ID: <CAP=4hCK=1kcOz6nmt-2OGBguh_pk_B42FXp5LVhbsqTB+grgZg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000032650905a7809ee8"
Subject: Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods
From: carusogabriel34@gmail.com (Gabriel Caruso)

--00000000000032650905a7809ee8
Content-Type: text/plain; charset="UTF-8"

On Wed, 3 Jun 2020 at 23:11, Gabriel Caruso <carusogabriel34@gmail.com>
wrote:

> On Wed, 3 Jun 2020 at 12:32, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Sun, May 31, 2020 at 11:20 PM Gabriel Caruso <
>> carusogabriel34@gmail.com> wrote:
>>
>>> On Sun, 31 May 2020 at 15:57, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>>
>>>> On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso <
>>>> carusogabriel34@gmail.com> wrote:
>>>>
>>>>> Hello, internals!
>>>>>
>>>>> I have opened the voting for
>>>>> https://wiki.php.net/rfc/magic-methods-signature.
>>>>>
>>>>> The voting period ends on 2020-06-19 at 18h (CEST).
>>>>>
>>>>
>>>> The RFC is a bit unclear on what is actually being proposed. It says
>>>>
>>>> > This RFC proposes to add parameter and return types checks per the
>>>> following details.
>>>>
>>>> and goes on to list (reasonable looking) magic method signatures, but
>>>> does not say how exactly those types are going to be checked. Is this going
>>>> to require exactly the same signature, or is this going to be in accordance
>>>> with variance rules? For example, are all of the following signatures valid
>>>> under this RFC? Only the first two? None of them?
>>>>
>>>>     // Narrowed return type from ?array
>>>>     public function __debugInfo(): array {}
>>>>
>>>>     // Narrowed return type from mixed
>>>>     public function __get(string $name): int {]
>>>>
>>>>     // Widened argument type from string
>>>>     public function __get(string|array $name): mixed {}
>>>>
>>>
>>>
>>> They are going to be checked following the variance rules, not the
>>> *exactly* same as the RFC. I'll mention this, thanks for point it out.
>>>
>>> Assuming this, your examples:
>>>
>>> 1 and 2. Will be valid, following the rules introduced by the `mixed`
>>> RFC.
>>>
>>> 3. Is that allowed in PHP? If so, the RFC will compliance with that.
>>>
>>
>> Yes, it is allowed. It makes little sense in this particular case, but
>> it's allowed.
>>
>
> Ok, so let's allow that as well. I'll cover that with tests.
>
>
>>
>> Also, is omitting the return type still permitted, even though it would
>>>> nominally violate variance?
>>>>
>>>>     public function __debugInfo() {}
>>>>
>>>
>>> Yes, this hasn't changed. The RFC only affects *typed* methods.
>>>
>>
>>>> Finally, if omitting the return type is permitted, will an implicit
>>>> return type be added, like we do for __toString()? Would the method
>>>> automatically become
>>>>
>>>>     public function __debugInfo(): ?array {}
>>>>
>>>
>>> An implicit return type won't be added for any of the magic methods. I
>>> believe that's a huge BC, and I don't want to debate that for PHP 8 (maybe
>>> PHP 9, yes).
>>>
>>
>> Why would this be a BC break? To make sure we're on the same page, I'm
>> suggesting to do the same as we do for __toString(), where if you declare
>>
>>     public function __toString() {}
>>
>> we automatically convert it into
>>
>>     public function __toString(): string {}
>>
>> internally.
>>
>
>> We could do the same for all other magic methods, and I don't think it
>> would introduce a particularly severe BC break.
>>
>> We did this for __toString() to work with the Stringable interface, and
>> we don't have the same requirement for other magic methods, but I still
>> think it's worth considering this for consistency reasons.
>>
>
> Ok, let me see if I understood it: so if someone creates a
>
>     public function __set($name, $value) {}
>
> we would automatically convert (as per this RFC) to
>
>     public function(string $name, mixed $value): void {}
>
> internally, right? Isn't this a BC if someone is returning something
> inside that method?
>
> Or no, are you talking that we only convert that for Reflection purpose?
>
>>
>> Nikita
>>
>

To exemplify my question: is this change that you are suggesting for us to
add: https://3v4l.org/JKj9f vs. https://3v4l.org/JKj9f/rfc#git-php-master?

--00000000000032650905a7809ee8--