Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115314
MIME-Version: 1.0
References: <CAF+90c8Qk4eMYCQLyX6DTsMFX_gxGg55PEKYfNXKigBpWdwBxg@mail.gmail.com>
 <CAOWwgp=YTiTi2kxtOTcXW4UFvva2vharhDpksjb8_L+My0xBbA@mail.gmail.com>
In-Reply-To: <CAOWwgp=YTiTi2kxtOTcXW4UFvva2vharhDpksjb8_L+My0xBbA@mail.gmail.com>
Date: Tue, 6 Jul 2021 12:31:58 +0200
Message-ID: <CAEPJdu=jXi+iLPben4NMJ_akV=8Ch1o_ub0Fxbayx43E7we3hw@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002b1b0405c671ef1c"
Subject: Re: [PHP-DEV] [Vote] New in initializers
From: kontakt@beberlei.de (Benjamin Eberlei)

--0000000000002b1b0405c671ef1c
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 6, 2021 at 9:31 AM Nicolas Grekas <nicolas.grekas+php@gmail.com>
wrote:

> Hi NIkita,
>
> I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting
> > will close on 2021-07-14.
> >
> > Note that relative to the original RFC, new support is limited to
> parameter
> > default values, attribute arguments, static variable initializers and
> > global constant initializers, and not supported in property initializers
> > and class constant initializers. The discussion thread
> > https://externals.io/message/113347 has some extensive information on
> how
> > we got here.
> >
>
> I voted yes and I'm happy this will come to PHP.
>
> I realized I still have one concern that I want to share here, related to
> attributes:
> The RFC breaks the possibility to parse the arguments of an attribute in a
> generic and safe way.
> What I mean is that right now, attributes can be inspected while the
> corresponding classes are not installed, due eg to a missing optional
> dependency.
>

This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and
then calling ReflectionAttribute::getArguments would also require to
resolve the type Foo. So this is not different than what could happen right
now already.

What you can do is use `ReflectionAttribute::getName()` to filter the
attributes you want to work on and only then call getArguments().


> This behavior is what makes attributes truly declarative: one can ignore
> what they don't care about. Extra semantics can be carried out by classes
> without making the related attributes a mandatory dependency.
>
> I think there is a way to preserve this behavior and that we should look
> for it.
>
> If I may propose one: we might add a new
> ReflectionAttribute::getUninitializedArguments() method, that would return
> the same as ReflectionAttribute::getArguments(), except that it would put a
> ReflectionAttribute (or similar) instance in place of objects in the data
> structure. As a corollary, we might also want to enforce that only child
> classes of the Attribute class can be nested inside another Attribute (at
> least if we want to reuse ReflectionAttribute as a placeholder.)
>

A function like this could return all arguments that are not AST Nodes but
"literals" (instances of scalar / array types).
Foo::class or new Foo() are both AST Node types that are resolved the same
way in `getArguments`.


>
> WDYT?
>
> Nicolas
>

--0000000000002b1b0405c671ef1c--