Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112106
To: Rowan Tommins <rowan.collins@gmail.com>, PHP Internals List
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] List of attributes
Thread-Index:
 AQHWlKduqAD4JLWTfUSbO6DleNAbtql92cYAgAAq64CAATgcAIAJ4ESAgBYMm8qAAZRFgIAEqHeB
Date: Fri, 23 Oct 2020 15:52:24 +0000
Message-ID:
 <BYAPR05MB547858A38633C2AF75A8567CDE1A0@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>
In-Reply-To:
 <CALKiJKqCMPdEOA-2_LPyBYeRRDEGh9TGgpFp0hWhTCxhCrs1og@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [2L/Yy2PVRhlT+Jj9l2n+C0pK41qVzJRp]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: e8fd0ee1-86f4-4510-e0fb-08d8776ba2c9
x-ms-traffictypediagnostic: CO1NAM11HT085:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 +2l1iBC7edsAggzEAV5tnjR7LODSVIMmmdItTbgtkaq27U/hZ74biulJ0zrZbXPqm60WvyWFFHjey9zgft4MMc8KF5ZGinsR1kiDjKX6rD4Nj7UftBOm9SliOyea58ornyy4NZlLUEDaZf3uUA3S5A2CchDIGH8mKrgxpxICIYaqhIReMELQ3sfIYjnliv+x6poG5McKIuyrFfknrziAcw==
x-ms-exchange-antispam-messagedata:
 /Bl+wW506zpaGxUeRSq6zfGf0TIdIPBjPUiaLcPkFV5n+jVZdOW/rj8vqu+GFol5LodI3l045WP9+74G1Z5P2nq7YWRZVlypY4ls5f1oXElkQGll+b32OszHTNNxo85kNcaSROAn9l7WqU1bIHDX2g==
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: CO1NAM11FT046.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: e8fd0ee1-86f4-4510-e0fb-08d8776ba2c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2020 15:52:24.7871
 (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: CO1NAM11HT085
Subject: Re: [PHP-DEV] List of attributes
From: theodorejb@outlook.com (Theodore Brown)

On Tue, Oct 20, 2020 at 10:13 AM Rowan Tommins <rowan.collins@gmail.com> wr=
ote:=0A=
=0A=
> On Mon, 19 Oct 2020 at 16:17, Theodore Brown <theodorejb@outlook.com> wro=
te:=0A=
> =0A=
> >=0A=
> > In theory nested attributes could be supported in the same way with=0A=
> > the `#[]` syntax, but it's more verbose and I think less intuitive=0A=
> > (e.g. people may try to use the grouped syntax in this context, but=0A=
> > it wouldn't work). Also the combination of brackets delineating both=0A=
> > arrays and attributes reduces readability:=0A=
> >=0A=
> >     #[Assert\All([=0A=
> >         #[Assert\Email],=0A=
> >         #[Assert\NotBlank],=0A=
> >         #[Assert\Length(max: 100)]=0A=
> >     ])]=0A=
> >=0A=
> =0A=
> I think you're presupposing how a feature would work that hasn't=0A=
> even been specced out yet. On the face of it, it would seem logical=0A=
> and achievable for the above to be equivalent to this:=0A=
> =0A=
>     #[Assert\All(=0A=
>        #[=0A=
>             Assert\Email,=0A=
>             Assert\NotBlank,=0A=
>             Assert\Length(max: 100)=0A=
>        ]=0A=
>     )]=0A=
> =0A=
> i.e. for a list of grouped attributes in nested context to be=0A=
> equivalent to an array of nested attributes.=0A=
=0A=
Hi Rowan,=0A=
=0A=
The problem with this is that it results in inconsistent semantics,=0A=
where the number of items in an attribute group results in a=0A=
different type of value being passed. I.e. if you remove two of the=0A=
three attributes from the list, suddenly the code will break since=0A=
the `Assert\All` attribute is no longer being passed an array.=0A=
=0A=
// error when Assert\All is instantiated since it's no longer being  =0A=
// passed an array of attributes:=0A=
=0A=
    #[Assert\All(=0A=
        #[=0A=
            Assert\Email,=0A=
        ]=0A=
    )]=0A=
=0A=
So when removing nested attributes from a list such that there's only=0A=
one left in the list, you'd have to remember to additionally wrap the=0A=
attribute group in array brackets:=0A=
=0A=
    #[Assert\All(=0A=
        [#[=0A=
            Assert\Email,=0A=
        ]]=0A=
    )]=0A=
=0A=
And of course when you want to add additional attributes to a group=0A=
that originally had only one attribute, you'd have to remember to=0A=
remove the extra array brackets.=0A=
=0A=
Generally speaking, having the number of items in a list change the=0A=
type of the list is a recipe for confusion and unexpected errors. So=0A=
I think the only sane approach is to ban using the grouped syntax in=0A=
combination with nested attributes.=0A=
=0A=
Unfortunately, no one thought through these issues when proposing to=0A=
change the shorter attribute syntax away from @@ and add the grouped=0A=
syntax, and now it seems like we're stuck with a syntax that is =0A=
unnecessarily complex and confusing to use for nested attributes.=0A=
=0A=
> Unless nested attributes were limited to being direct arguments to=0A=
> another attribute, the *semantics* of nested attributes inside=0A=
> arrays would have to be defined anyway (e.g. how they would look in=0A=
> reflection, whether they would be recursively instantiated by=0A=
> newInstance(), etc).=0A=
=0A=
Yes, the exact semantics of nested attributes need to be defined, but=0A=
this is a completely separate topic from the grouped syntax issue=0A=
described above.=0A=
=0A=
As a user I would expect nested attributes to be reflected the same=0A=
as any other attribute (i.e. as a `ReflectionAttribute` instance).=0A=
Calling `getArguments` on a parent attribute would return an array=0A=
with `ReflectionAttribute` objects for any nested attribute passed=0A=
as a direct argument or array value.=0A=
=0A=
On first thought I think it makes sense to recursively instantiate=0A=
nested attributes when calling `newInstance` on a parent attribute.=0A=
This would allow attribute class constructors to specify the type=0A=
for each attribute argument. But again, this is a separate discussion=0A=
from the issue of nested attribute syntax.=0A=
=0A=
Kind regards,  =0A=
Theodore=0A=