Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110354
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>
In-Reply-To: <CAF+90c_0N1sBn-LjDxeRUbF6=0MT6kUCoDpd+gzm=8Vh445yUA@mail.gmail.com>
Date: Wed, 3 Jun 2020 23:11:19 +0200
Message-ID: <CAP=4hCLBYA0Zz0ak1VierbBBnkEt7J8Fhm2NgVujWL2jNArTag@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000021318c05a7347911"
Subject: Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods
From: carusogabriel34@gmail.com (Gabriel Caruso)

--00000000000021318c05a7347911
Content-Type: text/plain; charset="UTF-8"

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
>

--00000000000021318c05a7347911--