Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112150
To: PHP Internals List <internals@lists.php.net>
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>
Message-ID: <258d9a8e-e73e-7b8a-5d9f-64a449def1da@gmail.com>
Date: Fri, 30 Oct 2020 19:28:41 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <BYAPR05MB5478A1FBBFC4F66CE8C4CF1CDE150@BYAPR05MB5478.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] List of attributes
From: rowan.collins@gmail.com (Rowan Tommins)

On 30/10/2020 18:47, Theodore Brown wrote:
> While passing all nested attributes as an array would at least enable
> consistent semantics, it has the notable disadvantage of preventing
> some use cases from being expressed in PHP's type system. Specifically,
> how would you express that an attribute parameter must be passed a
> single attribute of a particular type?


I acknowledged this use case, but suspected, and still suspect, that 
it's rarer than the list-of-attributes case.


> For example, suppose a developer wants to create/use an attribute
> like the following:
>
>      #[Limit(
>          min: 10,
>          max: 100,
>          error: #[CustomError(message: "...", notify: true, withTrace: false)]
>      )]


What is the fundamental advantage of using an attribute as the argument 
here? The same thing can be expressed with an associative array:

     #[Limit(
         min: 10,
         max: 100,
         error: ["message" => "...", "notify" => true, "withTrace" => false]
     )]

The only thing that seems to lose is the ability to specify the allowed 
names and types of options - but those won't be checked by the 
ReflectionAttribute anyway, only once the actual constructor is run. So 
there's nothing really "attribute-y" about the CustomError class, and 
any "static object declaration" syntax would do, e.g.

     #[Limit(
         min: 10,
         max: 100,
         error: CustomError{message="...", notify=true, withTrace=false}
     )]



> But if nested attributes are always passed as an array, the `$error`
> parameter would have to have an `array` type, which provides
> essentially no context about what is really required. The type system
> would be perfectly happy to allow an empty array, or an array with
> multiple values instead of the expected single `CustomError` attribute.


Again, this is a general problem, not one related to attributes: the 
Symfony validation examples would be best declared as requiring 
"Constraint[] $constraints" rather than "array $constraints".


> 3. Vote to switch to a less verbose syntax [...]
>     The downside is that...


Let me stop you there. The downside is that a mob of Internals regulars 
will come to your house and lynch you for asking them to vote on the 
same thing yet again. It just ain't gonna happen.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]