If we had true annotations, its certainly something the engine could put to use... See my previous post in this thread.
-Clint On Jan 8, 2013, at 7:38 PM, Rasmus Schultz <[email protected]> wrote: > 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 <[email protected]>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 >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
