Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111941
MIME-Version: 1.0
References: <CAOWwgpkDAq4d229Z3D3=xBWyX-z8N+qC-BG4j0uoZy4Xc6JLKQ@mail.gmail.com>
In-Reply-To: <CAOWwgpkDAq4d229Z3D3=xBWyX-z8N+qC-BG4j0uoZy4Xc6JLKQ@mail.gmail.com>
Date: Mon, 28 Sep 2020 12:24:26 +0200
Message-ID: <CAF+90c_8Q-tuE-waqLENoH=ZLknJZfZmiji1p0hqJWwAqSfieQ@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000168e1205b05d1329"
Subject: Re: [PHP-DEV] List of attributes
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000168e1205b05d1329
Content-Type: text/plain; charset="UTF-8"

On Sun, Sep 27, 2020 at 10:23 AM Nicolas Grekas <nicolas.grekas@gmail.com>
wrote:

> Hi Benjamin, hi everyone
>
> I'm wondering if the syntax that allows for several attributes is really
> future-proof when considering nested attributes:
>
>
> *1.*
> #[foo]
> #[bar]
>
> VS
>
>
> *2.*
> #[foo, bar]
>
> Add nested attributes to the mix, here are two possible ways:
>
>
> *A.*
> #[foo(
>     #[bar]
> )]
>
> or
>
>
> *B.*
> #[foo(
>     bar
> )]
>
> The A. syntax is consistent with the 1. list.
> I feel like syntax B is not desired and could be confusing from a grammar
> pov.
> BUT in syntax 2., we allow an attribute to be unprefixed (bar), so that
> syntax B is consistent with 2.
>
> Shouldn't we remove syntax 2. in 8.0 and consider it again when nested
> attributes are introduced?
>
> I voted yes for syntax 2. when the attributes were using << >>. I would
> vote NO now with the new syntax.
>
> Nicolas
>

As far as my understanding goes, if we introduce "nested" attributes, it
will be in the form of relaxing constraints on constant expressions, i.e.
by allowing you to write #[Attr(new NestedAttr)].

Nikita

--000000000000168e1205b05d1329--