Re: List of attributes

On 30 October 2020 21:54:10 GMT+00:00, Theodore Brown <theodorejb@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]