[RFC] [VOTE] PHP Attributes

On 5/10/2016 8:29 PM, Dmitry Stogov wrote:

I hope it's going to be negative. The name is misleading and the AST approach is not really useful in userland. :(

A couple of quick comments - I'm sorry, I haven't had time to get them in before now. In my opinion, this is pretty bad, for one primary reason: these are just names and values. The advantage of this over parsing doc-blocks at run-time is pretty limited - you can basically only guarantee syntax, you can't guarantee anything about annotation types or the required arguments. Names and values still need to be resolved at run-time - that seems really brittle and redundant. It's also not what the community wants - they want classes, e.g. Doctrine annotations, the most popular choice: https://github.com/doctrine/annotations Or the project that I started (but no longer contribute to) https://github.com/php-annotations/php-annotations/ We want classes for the same reason we don't want arrays with magical key/value pairs - for example, so we can have static analysis, inspections, auto-completion in IDEs, etc. Annotations need more consideration for design time - run time attributes, in my opinion, is not enough, and brings more net complexity than actual annotations. Because no behavior or coupling is defined, they won't behave well, and the coupling will be unpredictable - we'll have lots of frameworks, all doing things differently, which is the same situation we have now. In my opinion, if we need this functionality at all, we need real annotations - not just new syntax for the data, but taking into account the behavior. I think annotations could be as simple as this: https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46 In my opinion, this immediately solves a lot more problems with a lot less effort (and fragmentation!) in userland. It's immediately useful in any script, without having to select and install a third-party Composer package or write complex code to interpret the data. As for "softer" and more complex rules, e.g. regarding the number of allowed annotations of the same type, or the type of element they're allowed on, etc. - it doesn't make much sense to try to implement or enforce such rules, as these wouldn't be enforced until the moment you actually query the annotations of an element anyhow. This could be either left up to userland, e.g. consumers can easily check and enforce constraints themselves using conditionals and exceptions. As for single vs multiple annotations of the same type, I would ignore this as well, for the same reason - even if you had an API like getSingleAnnotation($type) this would have to return either an instance of $type, or null, so the consumer is still left with the burden of having to check the result, e.g. no more or less of a burden than checking the number of returned annotations with count(). To summarize: - Annotations are immediately useful in any script - Annotations are coupled directly to classes - Classes is what most of us want in the end - Static type-checking is possible I think that attributes are not the way to go about this - it's not substantially better than the status quo and doesn't lead to anything immediately useful to most developers without also adopting/writing/learning a suitable framework. Just my opinions. On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov <dmitry@zend.com> wrote:

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov <dmitry@zend.com> wrote:

one question, Rasmus Schultz post goes into the similar direction. Any reason why the annotations are only a numeric list and not key value pairs? Key-Value would be much more powerful and address a ton of objections for us (Doctrine). In the current state it is pretty limited for more complex use-cases. I don't want to fully embrace the complexities that Larry showed for Drupal (in my opinion, too much annotations), but without key value pairs we could only use this when we nested JSON into the attribute value strings for example, not something I want to mix.

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Thanks for the good work. Regarding naming, I googled "PHP attributes" vs "PHP annotations" and looking at the result, my view is that that Annotation is a better naming then Attributes. Any hope in changing it? Regards //Björn Larsson

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov <dmitry@zend.com> wrote:

I voted -1 Reasons: from a Doctrine Annotations maintainer perspective, either getting a list (without keys) of strings back or ast\nodes are not enough or way too advanced for our use-case. The middle ground is missing where a <php-constant> (Name borrowed from the RFC) can be an arbitrarily deep nested array, that means getAttributes() does should not only return "string" or ast\node as result for each attribute, to there should be a way to get arrays back. Example: https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25 greetings Benjamin