Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110353
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> <CAPVMwwsmCievEbQ5XaB-MV7ck19n7MpQfgJpeEiUpjNEV8OvEQ@mail.gmail.com>
In-Reply-To: <CAPVMwwsmCievEbQ5XaB-MV7ck19n7MpQfgJpeEiUpjNEV8OvEQ@mail.gmail.com>
Date: Wed, 3 Jun 2020 23:05:30 +0200
Message-ID: <CAP=4hCKATrejdhREJRYC_uGQkqvd=8VXBB76j-Y6f+B28dweUA@mail.gmail.com>
To: Dmitry Stogov <dmitrystogov@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000515fcc05a734645d"
Subject: Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods
From: carusogabriel34@gmail.com (Gabriel Caruso)

--000000000000515fcc05a734645d
Content-Type: text/plain; charset="UTF-8"

>
> On Mon, Jun 1, 2020 at 12:20 AM 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.
>>
>>
>> >
>> > 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).
>>
>>
>> >
>> > and report as such from reflection?
>> >
>>
>> I need more clearance on this one: are you asking how magic methods are
>> reported via Reflection and if that will be changed?
>>
>>
>> >
>> > Nikita
>> >
>>
> On Tue, 2 Jun 2020 at 14:26, Dmitry Stogov <dmitrystogov@gmail.com> wrote:

> Does this RFC support __get() returning by reference?
> See
> https://github.com/php/php-src/blob/master/Zend/tests/overloaded_prop_assign_op_refs.phpt#L11
>
> Thanks. Dmitry.

Hello Dmitry,

Yes, I'm not changing any behavior of magic methods and references.

-- Gabriel Caruso

--000000000000515fcc05a734645d--