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.
>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
