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 <dmi...@zend.com> wrote: > Hi internals, > > > I've started voting on "PHP Attributes" RFC. > > > https://wiki.php.net/rfc/attributes > > > In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but > it's not going to be the end of the world, if we decided to live with > doc-comments only. > > > Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
