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

Reply via email to