Re: Re: [mail] Re: [PHP-DEV] Re: Attributes support proposal
| From: | Andrey Hristov | Date: | Wed, 27 Apr 2005 13:51:53 +0000 |
| Subject: | Re: Re: [mail] Re: [PHP-DEV] Re: Attributes support proposal | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-16116@lists.php.net to get a copy of this message | ||
Hi,
Duncan McIntyre wrote:
On Wednesday 27 April 2005 2:19 pm, Zeev Suraski wrote:Wooha, what a beastie, 350 kloc. Never seen such a thing in PHP.At 16:58 27/04/2005, Duncan McIntyre wrote: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.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.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 :-(If you are worried about removing bloat, I suggest removing doc commentsfrom the engine. You are already storing the filename and linenumber whereelements 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.