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().
- 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 wrote:
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.