On 2011-05-11, dukeofgaming <dukeofgam...@gmail.com> wrote: > On Wed, May 11, 2011 at 12:41 AM, Lester Caine <les...@lsces.co.uk> wrote: > > guilhermebla...@gmail.com wrote: > > > So, please stop saying "no" to every feature request that comes in > > > and start to discuss the actual impact of each feature. > > > > I think that MY only problem with you 'adding annotations because it > > is missing' is simply that I've already been doing it for years - > > just not calling it 'annotations' ... its 'documentation' and always > > has been ... > > It is really troubling to read that statement. Seems there are still > some that don't really have a clue of what annotations are, even when > the RFC clearly links to them. Annotations ARE NOT documentation; in > the case of PHP, documentation is being used as annotations because > there is no language implementation, which exists in other languages > (Java, .NET) and they are widely used. Also, some use annotations as > documentation (e.g. store the class version), but again, annotations > ARE NOT documentation. Don't let the "@" notation shared with docblock > fool you.
That may be the case. However, annotations within docblocks have been the de facto standard for going on a decade. Adding a new language feature at this point means several things: * Developers using annotations in docblocks now need to consider migrating to "true" annotations, which in turn means... * BC break of their code with previous versions of PHP. * In many cases, not only are code changes needed (moving annotations out of docblocks), but also likely the code handling the annotations will need to be updated -- which means at least one if not several maintenance cycles. Expensive. * And don't forget the cases where docblock annotations were serving multiple purposes. A good example: ZF server classes utilize the same docblock annotations used by phpDocumentor (well, now DocBlox!) in order to deliver method signatures to clients. Switching to annotations would end up duplicating information in this use case. The point that myself and others have been trying to make is that we may agree with the need for annotations, but due to the long-standing history of using annotations in docblocks, coupled with the desire to reduce potential BC breaks and maintenance cycles, we'd prefer to see an annotation parser for docblocks vs a new language syntax. > Guilherme, I think its easy to assume that people already have some > sense of what annotations are, but perhaps the wiki entry could be > more educational about it?. The first time I read about annotations it > was from this link: > http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html; > perhaps an intro like that could help to make the case for annotations > crystal clear?. > > > > > > The real problem at present is that the whole ecosystem is now so > > disjointed that PHP5.2 is the last version that is still fairly fully > > supported, but people are pushing for 5.4 before 5.3 has been properly put > > to bed. We need to finish of what is already added fully before pushing more > > new stuff in? That INCLUDES in the ecosystem! > > > > And we still have the hole that is unicode ... > > > > This is another thing that troubles me when I read this list. How does the > PHP core dev community sets priorities?, is there some sort of roadmap?, is > there a process to create this roadmap?, or is it just all a generalized > best intention to do things. > > I'm aware that the more features the more has to be maintained, but, what I > see is that there is lot of potential for the core dev community to grow and > at its current state it doesn't seem to be able scale due to the lack of a > roadmap/process. > > I'm not trying to be a douche here, just saying: I see lots of criticism > towards everything and very few agreements. > > Best regards, > > David Vega > > --0016e6d260d294be9504a2fa7db4-- -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
