On 30 October 2020 21:54:10 GMT+00:00, Theodore Brown <theodor...@outlook.com>
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.
Yes, in general being able to declare structures rather than associative arrays
is useful. Note though that that's not unique to attributes, nor are third
party static analysers limited by the native facilities of the language.
>> So there's nothing really "attribute-y" about the CustomError class,
>
>What do you mean by "attribute-y"?
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.
>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.
I don't understand what the advantage of that would be in this case. 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 array?
>> and any "static object declaration" syntax would do, e.g.
>>
>> #[Limit(
>> min: 10,
>> max: 100,
>> error: CustomError{message="...", notify=true,
>withTrace=false}
>> )]
>
>It's not clear what exactly you're proposing here, or how it would
>work.
I don't want to get bogged down in the details, it was just a quick example;
the point I was trying to make was that if CustomError is just a data object,
then the requirement is some syntax for creating data objects in scopes where
that's not currently allowed. That includes in the arguments to attributes, but
also includes, for instance, constants, property defaults, and parameter
defaults.
>There is no general problem of not being able to specify that a
>parameter takes a single object with a particular type.
No, but there's a general problem of not being able to specify that a parameter
takes a list of a certain type, and this would be one of many, many places
where that is a minor nuisance largely solved by third party static analysis
tools.
> This would be
>an artificial limitation on attributes to patch over the inherent
>inconsistency of the grouped syntax for nested attributes.
There is no artificial limitation; there is a binary choice: does #[Foo]
represent an object or a list with one item in? This is completely new syntax,
so there is nothing for it to be inconsistent with other than itself.
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, they
are always retrieved as a list.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
