Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112284
To: Larry Garfield <larry@garfieldtech.com>, Rowan Collins
	<rowan.collins@gmail.com>
CC: php internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] List of attributes
Thread-Index:
 AQHWlKduqAD4JLWTfUSbO6DleNAbtql92cYAgAAq64CAATgcAIAJ4ESAgBYMm8qAAZRFgIAEqHeBgAgHdACAABBagIADMPVMgAANRYCAABWhiYAA34aAgADzwYCAJZ6FFQ==
Date: Tue, 24 Nov 2020 23:09:44 +0000
Message-ID:
 <BYAPR05MB5478007C3FB508E5C563BC2ADEFB0@BYAPR05MB5478.namprd05.prod.outlook.com>
References:
 <CAOWwgpkDAq4d229Z3D3=xBWyX-z8N+qC-BG4j0uoZy4Xc6JLKQ@mail.gmail.com>
 <CAF+90c_8Q-tuE-waqLENoH=ZLknJZfZmiji1p0hqJWwAqSfieQ@mail.gmail.com>
 <CAOWwgpmMhKDoeawbN23nGuR7J6A=AUfbZ4W+PNUkFACMDmvkhg@mail.gmail.com>
 <CAEPJdunxkKSRTxUhT13F-NAO4+3wmMJ3tanfFYh-iV6JUpUQDA@mail.gmail.com>
 <CAOWwgpkrNAVMZ6yj5eZhkd=aCC=x71V8hsLKxvdhqHoR6DKUuQ@mail.gmail.com>
 <BYAPR05MB54782200D1C1505A4EF85BCFDE1E0@BYAPR05MB5478.namprd05.prod.outlook.com>
 <CALKiJKqCMPdEOA-2_LPyBYeRRDEGh9TGgpFp0hWhTCxhCrs1og@mail.gmail.com>
 <BYAPR05MB547858A38633C2AF75A8567CDE1A0@BYAPR05MB5478.namprd05.prod.outlook.com>
 <CAOWwgpmREMkGHvAQMPuUsJckG-5AvGyvpxcc0nh-ZWq9PjuW8Q@mail.gmail.com>
 <d335ed43-c797-ddb6-94f2-0588a77b20bf@gmail.com>
 <BYAPR05MB5478A1FBBFC4F66CE8C4CF1CDE150@BYAPR05MB5478.namprd05.prod.outlook.com>
 <258d9a8e-e73e-7b8a-5d9f-64a449def1da@gmail.com>
 <BYAPR05MB54783D66EAC1C8DAEEBAB48FDE150@BYAPR05MB5478.namprd05.prod.outlook.com>
 <F681ECFA-910F-475A-8DBA-36FB9F1AA805@gmail.com>,<c5a887a6-c062-46fb-8752-25ea89f4f8b9@www.fastmail.com>
In-Reply-To: <c5a887a6-c062-46fb-8752-25ea89f4f8b9@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [23k84xoJNJlxmn97Ft72JVK9m/Y8n95q]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: feaf4004-63af-4fec-97c6-08d890ce0809
x-ms-traffictypediagnostic: MW2NAM10HT167:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 wqMTQL9XHCRtgKGTDL7jQ/L453DgEVqUj+WbUYc4q5TEeyktmIackyhSUG9wj0fB/+12vVx4PLEb3vwSL7cvgyrOEdWtYVv0dQL1flYtLZfwy0OtTDklhrVh0cTJeBaFsTvLdSaNXV4frqFmq+fEj6SUZcfvNbiQ2DBLFgZ8cmaiMFmkiRLwzeLq4NCIgF6flAH/HmisJ+RgUvExNRLg9Q==
x-ms-exchange-antispam-messagedata:
 INf4awWk61WRnhB5SnI2Ihn9H0uWSgbau6Dct0IGnkFTNBFZGQtuZhXWIJyJKzUy+zZaFsv5mK79VjDbZ1Y0HdgjfWyuFwXWpKLTbzbgvS3FbE11PbV04BTuOMEYg1fqYZdxt/Hu5VHK5g25SkdIOw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM10FT060.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: feaf4004-63af-4fec-97c6-08d890ce0809
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 23:09:44.4444
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM10HT167
Subject: Re: [PHP-DEV] List of attributes
From: theodorejb@outlook.com (Theodore Brown)

On Sat, Oct 31, 2020, at 5:06 AM, Rowan Tommins wrote:=0A=
=0A=
> > This would be an artificial limitation on attributes to patch=0A=
> > over the inherent inconsistency of the grouped syntax for nested=0A=
> > attributes.=0A=
>=0A=
> There is no artificial limitation; there is a binary choice: does=0A=
> #[Foo] represent an object or a list with one item in? This is=0A=
> completely new syntax, so there is nothing for it to be inconsistent=0A=
> with other than itself.=0A=
=0A=
It is very much an artificial limitation. Developers would be prevented=0A=
from declaring that an attribute must be passed a single attribute =0A=
with a particular type as one of its parameters. This isn't a natural=0A=
or inherent limitation of attributes, but an artificial one in order=0A=
to try to make the `#[Attr1, Attr2]` grouped syntax usable with nested=0A=
attributes.=0A=
=0A=
> I am arguing that having it represent a list with one item in is=0A=
> actually *more* consistent, because when you attach attributes to a=0A=
> declaration, they are always retrieved as a list.=0A=
=0A=
That's not necessarily the case for nested attributes. A developer=0A=
may want to declare that an attribute constructor takes a single=0A=
attribute with a particular type as one of its arguments. Why should=0A=
PHP prevent this by only allowing a (possibly empty) list to be=0A=
passed? Again, this would be an artificial limitation that reduces=0A=
the flexibility and usefulness of nested attributes.=0A=
=0A=
On Sat, Oct 31, 2020 at 7:38 PM Larry Garfield <larry@garfieldtech.com> wro=
te:=0A=
=0A=
> Perhaps a naive question, but I'm missing the downside of:=0A=
> =0A=
>     #[Foo(Bar(name=3D"baz"))]=0A=
> =0A=
>     #[Attribute]=0A=
>     class Foo {=0A=
>       public function construct(public Bar $bar) {}=0A=
>     }=0A=
> =0A=
>     class Bar {=0A=
>       public function construct(public string $name) {}=0A=
>     }=0A=
> =0A=
> Why is that not OK?  Someone mentioned it means you couldn't call a=0A=
> function there, but... that's not a huge problem because I can't=0A=
> imagine why you would.  If we really wanted to avoid that:=0A=
> =0A=
>     #[Foo(new Bar(name=3D"baz"))]=0A=
>=0A=
> That would be unambiguous, if a bit ugly.=0A=
=0A=
As I mentioned in my first email in this thread, there was an attempt=0A=
to do this back when the original `<<>>` attribute syntax was being=0A=
implemented. But this approach ran into difficulties since it would=0A=
require significant changes to constant expressions.=0A=
=0A=
Even if someone finds a reasonable way to make such a syntax *work*,=0A=
it still has the downside of requiring a different syntax for top-=0A=
level and nested attributes (docblock annotations allow using the=0A=
same syntax for both). Moreover, re-purposing the syntax for function=0A=
calls or class instantiation is likely to cause confusion, since it=0A=
looks like the code is doing something other than what it actually=0A=
does (and of course it would prevent ever extending constant=0A=
expressions to support function calls or class instantiation).=0A=
=0A=
One of my main motivations for proposing the `@@` shorter attribute=0A=
syntax was to avoid the complexity of grouped declarations and allow=0A=
using a single consistent syntax for both top level and nested=0A=
attributes. I fear that the change to the `#[]` syntax with grouping=0A=
will prevent PHP from getting a flexible and intuitive nested=0A=
attribute implementation, and devs will be forced to stick with=0A=
docblock annotations for these use cases.=0A=
=0A=
Kind regards,  =0A=
Theodore=0A=