I hear a lot of interesting arguments in this big annotation discussion, and now there's the ongoing vision discussion, which got me thinking.
It is true that there is broad community interest in annotations - part of the problem here, is that different groups have differing opinions about precisely what annotations are, how and when they should be used, the syntax, and a bunch of other things. To name a similar example, there is also broad community interest in e-mail clients - and countless userland implementations. Nobody is pushing for a standard e-mail client in PHP. Granted, e-mail is a run-time library feature, not a language feature, but I don't think it's an unfair comparison, since annotations aren't really so much a language feature either, if you think about it - much of the discussions revolve around API issues, and like someone pointed out, you could do metadata in other ways, without altering the language or parsing docblocks. I'm not making this point to argue against annotations, but it lead me back to another idea that has surfaced in discussions before: a source-directive feature. This sounds like a much smaller feature, which would be much simpler to define and agree on, and much simpler to implement. A source-directive would empower the community to define and implement the syntax, and not only for annotations, but for other features, such as aspect-oriented programming, which I believe was once proposed as an RFC (?) and declined, probably for the same reason... it's a feature with too many variations and opinions, lots of complexity, and it's probably another one of those language-features where the discussions end up revolving around run-time issues more so than language/syntax. It would be nice if every developer in the world could all agree on everything. But we can't, we don't, and we're not going to - and that's not a bad thing, because it means PHP is open for innovators to find better ways to do certain things in userland :-) The big advantage to having something like implemented and maintained in userland, is that these features can thrive and grow if they turn out to be successful - or, if everyone decides in a year or two that annotations suck, they can stop using them and move on to something else. It also means that developers don't need to wait for a year or more for their sysadmin to deploy the next minor PHP update that fixes a bug or makes a minor addition to that feature. Perhaps it's time to think about "lower level" language features that facilitate implementing "borderline" language-features, and enable the community to write better, more reliable implementations of things like annotations and AOP, rather than writing it for them? And perhaps a source-directive isn't the solution in this case, or perhaps it's only part of the solution - but what I'm saying is, maybe instead of lumping on more features that do one thing, perhaps it's time to turn things around, view things in a different light, and try to think about things on a somewhat more "meta" level? What's are the smallest "building block" language features that would enable the community to build bigger features such as annotations in a better way? I love annotations. But I love my implementation of annotations, I probably won't like yours, and that's not necessarily something we should need to agree upon. Is it really the responsibility of the language to deliver high-level features that support patterns? Or should it deliver simpler features that support the implementation of those patterns? - Rasmus Schultz
