Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110333
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>
In-Reply-To: <CAP=4hCJg595KnHdgDv5m__RYqKnTCRyW+zJfJWR9hhY_+1b4-w@mail.gmail.com>
Date: Tue, 2 Jun 2020 15:26:28 +0300
Message-ID: <CAPVMwwsmCievEbQ5XaB-MV7ck19n7MpQfgJpeEiUpjNEV8OvEQ@mail.gmail.com>
To: Gabriel Caruso <carusogabriel34@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f699b205a71905c0"
Subject: Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods
From: dmitrystogov@gmail.com (Dmitry Stogov)

--000000000000f699b205a71905c0
Content-Type: text/plain; charset="UTF-8"

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.

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
> >
>

--000000000000f699b205a71905c0--