Re: [mail] Re: [PHP-DEV] Re: Attributes support proposal
| From: | Duncan McIntyre | Date: | Wed, 27 Apr 2005 13:58:32 +0000 |
| Subject: | Re: [mail] Re: [PHP-DEV] Re: Attributes support proposal | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-16110@lists.php.net to get a copy of this message | ||
On Wednesday 27 April 2005 1:28 pm, Zeev Suraski wrote:
> At 20:12 25/04/2005, Christian Schneider wrote:
> >[snip]
> >But then again I think the whole thing is typical OO bloat anyway and
> >that's why I don't want to have language features added for it (-:C
>
> I wholeheartedly agree.
>
> Zeev
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?
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.
Or again, how is this more bloated than named parameters?
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!
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?
Duncan