Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112156
Date: Sat, 31 Oct 2020 10:06:07 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <BYAPR05MB54783D66EAC1C8DAEEBAB48FDE150@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>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: PHP Internals List <internals@lists.php.net>
Message-ID: <F681ECFA-910F-475A-8DBA-36FB9F1AA805@gmail.com>
Subject: Re: [PHP-DEV] List of attributes
From: rowan.collins@gmail.com (Rowan Tommins)

On 30 October 2020 21:54:10 GMT+00:00, Theodore Brown <theodorejb@outlook=
=2Ecom> wrote:
>The fundamental advantage of using an attribute here instead of an
>associative array is that it enables IDE autocompletion, and allows
>static analyzers to catch any mistakes in the parameter names/types
>before the code runs in production=2E


Yes, in general being able to declare structures rather than associative a=
rrays is useful=2E Note though that that's not unique to attributes, nor ar=
e third party static analysers limited by the native facilities of the lang=
uage=2E


>> So there's nothing really "attribute-y" about the CustomError class,
>
>What do you mean by "attribute-y"?=20


I mean that unlike the Symfony examples, CustomError is not something that=
 you'd use as an attribute on its own, actually attached to a declaration; =
it's just a container for some data=2E=20



>The `CustomError` class would be a
>normal attribute, and as such when calling `getArguments()` on the
>`Limit` ReflectionAttribute it would return a ReflectionAttribute for
>`CustomError`, which would allow its arguments to be inspected without
>loading the class=2E


I don't understand what the advantage of that would be in this case=2E If =
you "inspect" the arguments without running the constructor or even loading=
 the class definition, isn't that just the same as having an associative ar=
ray?


>> and any "static object declaration" syntax would do, e=2Eg=2E
>>=20
>>     #[Limit(
>>         min: 10,
>>         max: 100,
>>         error: CustomError{message=3D"=2E=2E=2E", notify=3Dtrue,
>withTrace=3Dfalse}
>>     )]
>
>It's not clear what exactly you're proposing here, or how it would
>work=2E


I don't want to get bogged down in the details, it was just a quick exampl=
e; the point I was trying to make was that if CustomError is just a data ob=
ject, then the requirement is some syntax for creating data objects in scop=
es where that's not currently allowed=2E That includes in the arguments to =
attributes, but also includes, for instance, constants, property defaults, =
and parameter defaults=2E=20


>There is no general problem of not being able to specify that a
>parameter takes a single object with a particular type=2E=20


No, but there's a general problem of not being able to specify that a para=
meter takes a list of a certain type, and this would be one of many, many p=
laces where that is a minor nuisance largely solved by third party static a=
nalysis tools=2E



> This would be
>an artificial limitation on attributes to patch over the inherent
>inconsistency of the grouped syntax for nested attributes=2E


There is no artificial limitation; there is a binary choice: does #[Foo] r=
epresent an object or a list with one item in? This is completely new synta=
x, so there is nothing for it to be inconsistent with other than itself=2E

I am arguing that having it represent a list with one item in is actually =
*more* consistent, because when you attach attributes to a declaration, the=
y are always retrieved as a list=2E


Regards,

--=20
Rowan Tommins
[IMSoP]