Hi,
Duncan McIntyre wrote:
On Wednesday 27 April 2005 2:19 pm, Zeev Suraski wrote:
At 16:58 27/04/2005, Duncan McIntyre wrote:
I remember similar arguments being made about most of the new OO features in PHP5.
Out of interest, how is this more bloated than storing doc comments in memory?
It's feature bloat, not memory consumption bloat. Adding obscure operators is the worst thing to do, since it reduces readability and complicates the language. Comments can be ignored, removed, be completely 'broken', etc. - you can use them if you understand them and they're useful to you, but you'll never get a piece of code which you wouldn't understand because of the comment. Not so with features such as attributes.
Moving this sort of metadata away from the element it belongs to and declaring it in another method or property doesn't do much to help understanding either. Interfaces or not.
If you are worried about removing bloat, I suggest removing doc comments
from the engine. You are already storing the filename and linenumber where
elements are defined, retrieving associated doc comments could happen in userland and a lot of memory would be saved.
Again, I care less about memory consumption (which is quite small in both cases), and more about readability and intuitiveness.
Hmm. As I mentioned to Christian in a private email, I have a system which is 350K LOC. Now not all of that gets loaded at one time of course (thank God for __autoload()!), but there are times when a significant proportion of it is loaded. And then it munches memory. Yes, I can strip the comments from production code. But that defeats the object of the getDocComments() reflection code. And screws me for my fallback attributes methodology :-(
Wooha, what a beastie, 350 kloc. Never seen such a thing in PHP.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
