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.
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.
Or again, how is this more bloated than named parameters?
This one is arguable, but subjectively, I think that both the concept and syntax of named arguments are very intuitive, if only for being standard in most of the languages PHP borrows syntax from.
There are reasons why modern languages provide this feature: because it's useful and because you cannot emulate it. And no, rigidly enforced variable naming schemes are not a substitute - what about inheritance? multiple declarations?. Of course if you think that is a substitute, then why not go the whole hog and require classes to declare the methods listProperties() and listMethods() and do away with reflection entirely? That's just OO bloat too.
When you need a feature like this and it doesn't exist, the workarounds lead to
- fragile classes as consumer classes need to know implementation details of the classes they consume, rather than being able to use reflection.
- bloat in the application code.
- disconnect between the declaration of an element and the information the class wishes to provide about the element. Imagine if public/private/protected didn't exist. I can imagine a ghastly workaround which would work, but you wouldn't want to use it. Same goes for attributes: they are an intrinsic property of an element, and to declare them somewhere else in the code makes no sense.
The implementation requires as much space in the property_info struct as doc_comment, and twenty lines of c code. Not a lot. And the work's been done for you already!
Yes, drawing the line of what should go into PHP and what shouldn't is a tough job. We may have already gone too far with what we've done with PHP 5, although I don't think we did. What that means is that not every useful feature should find its way into the language, since the biggest advantage PHP has is not the richness of its features, but the facts they glue together nicely into a language that's very easy to use.
If in the few cases where attributes are required you'd have to implement a couple of more interfaces and complicate your code, so be it, it's much better than introducing a feature that would be useful for very few and at the same time decrease the readability of the language.
How about a deal: I'll remove the doc_comment code from the engine and put it into the reflection api if you'll accept my attributes patches. You'll end up with a faster engine which uses less memory, and the rest of us will get a seriously useful new feature. How about it?
I'm not too thrilled about this deal. I don't think I'd be in favour of accepting this attributes patch regardless of just about anything else. Not sure how others feel about it, but at least in my opinion, this feature is a clear 'no no' for PHP.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
