Hi Lester, What you don't see is that you're against having it because you already had the effort to built this support. So answering your question related to use cases, you own codebase is a good example.
You had to create a parser for docblock because PHP doesn't have support. And now you're asking me why is it needed because you already implemented it. It's like chicken and eggs. You wouldn't need to implement a docblock parser IF PHP already supported it. Also, you own comments answer you own question. You "compile" your code for production removing the docblocks (or adding a cache, or generating a file, etc, whatever you want). What does it prohibit you from doing the same with native support? Regards, On Mon, May 9, 2011 at 9:25 PM, Lester Caine <les...@lsces.co.uk> wrote: > guilhermebla...@gmail.com wrote: >> >> Hi Lester, >> >> I updated the RFC. I may have missed one thing or two, but overall >> idea and how code behave is there. >> This question is answered on wiki RFC. =) >> >> Here is the direct link: https://wiki.php.net/rfc/annotations > > But there is nothing there that explains why this is any use where we are > not compiling code ... and are all things we are already doing with comment > blocks ... which CAN be stripped to speed up operation once in a production > environment. A compiler simply strips the unnecessary stuff when building > the running code, how do you propose PHP does that ? If I want compiled code > then I can use any number of other languages, PHP simply runs what I have in > the file. > >> Regards, >> >> On Mon, May 9, 2011 at 6:42 PM, Lester Caine<les...@lsces.co.uk> wrote: >>> >>> guilhermebla...@gmail.com wrote: >>>> >>>> What I thought it could be changed is: >>>> - Allow PHP to support it natively and also take advantage of opcode >>>> cache >>>> - Make API cleaner >>> >>> Guilherme you still also have to explain WHY we need this. I have a >>> perfectly functional documentation and hinting setup working from >>> docblock >>> entries in several years worth of code. Rewriting all of that would have >>> to >>> have some reason, and working with two systems in parallel does not make >>> sense. My current method of working is well supported in phpeclipse while >>> your new offering will require some major work in phpeclipse and other >>> tools >>> simply to access it? More work for other open source developers who again >>> probably don't need it. So as far as I am concerned I need to be >>> persuaded >>> why this code needs to be IN the core code when I for one can't see any >>> reason to use it. Just because COMPILED languages have it is not a reason >>> to >>> load an interpreted language with it. Adding it as a removable extension >>> might make more sense to me, just as much of the less used code can be >>> disabled if we want. And I was coding in C/C++ long before I switched TO >>> PHP >>> to get away from the problems of using compiled languages for dynamic web >>> based systems. > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
