To summarize: A native implementation of PHP-DOC block parser for run-time purposes (annotation libraries) is already available in the Reflection API, and already goes as deep as it needs to - going beyond simply finding and extracting the docblocks would make little sense, as every annotation library has it's own individual syntax, behaviors and features. There may be a some libraries that could use a native implementation if it happens to fit their needs, but they most likely won't use it, because (A) they won't win anything by doing so, and (B) these libraries would become incompatible with anything other than bleeding-edge PHP.
A native implementation of PHP-DOC parser for offline purposes (documentation generators) is already available in userland, does the job fine, and does not rely on the Reflection API (as someone mentioned) because loading every class in a large codebase is not feasible. If you provide a separate PHP-DOC parser, these projects most likely won't use it, because (A) see above and (B) see above. Who else would need to parse PHP-DOC blocks and why? Bottom line, who is this feature for, what will they do with it, and most importantly, why would they use it? On Tue, Jan 8, 2013 at 3:55 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote: > Hi! > > > First of all, there are already plenty of established userland > > implementations - so there is really no need for this. > > On the contrary, plenty of implementations means there's a need in this > functionality, and it might be a good idea to have one standard > implementation if it can cover like 80% of use cases. > > > > > Whatever you decide on in terms of syntax, most likely won't satisfy > every > > the needs of every userland annotation library, so at least some of them > > most likely won't use it. You'd be creating more work for the maintainers > > of these frameworks, and they don't standard to gain anything from that > > work. > > Since when "it does not satisfy all needs of all users, and some of them > may end up not using it" is an argument for not including functionality? > And how it's more work for maintainers if they just won't use it? > > > On the other hand, I would be interested in having support for actual > > annotation syntax (not docblocks) added to PHP. Real annotation syntax > > Can we please not hijack the topic? We discussed annotations many times > already, if you have better proposal than current RFCs please create > your own RFC (or ask one of the current RFC authors for collaboration) > and start a new topic > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >
