Kristian Koehntopp wrote:
> On Thu, Apr 04, 2002 at 03:06:30PM -0800, Shane Caraveo wrote:
>
>>>Recommendation:
>>>
>>>If overload() indeed supports variably named callback functions
>>>such as __get_x(), support for this should be removed in order
>>>to avoid a number of possible inconsistencies and namespace
>>>pollution.
>>>
>>
>>Yes it does support it. No it shouldn't be removed. Why not explain
>>the problems you perceive.
>
>
> 1. Variant:
>
> class A {
>
> function __get_x(...) {
>
> }
> }
>
> class B extends A {
>
> }
>
> overload("B");
>
> Does A::__get_x() magically become an automated callback in B?
> When A was written, it was obviously never intended to be one.
> How is this being handled?
I'm not sure how it's being handled, been a while since I've looked at
the overload code. I feel it should be overloaded. I don't see that it
was obviously never meant to be a getter. To me, there is a specific
syntax to getters/setters/call handlers, and a class written with them
should expect they be used that way.
> 2. Variant:
>
> class C {
> ...
> }
>
> overload("C");
>
> $c = new C;
> aggregate($c, "A");
>
> Again, does A::__get_x() magically become an automated callback
> in C? How is this being handled?
Again, I feel A should be overloaded.
> Generally speaking, automated callback functions such as
> constructors, destructors, getters, setters and wrappers should
> never have variable names. They shall use only a small and
> clearly defined part of the namespace. All kind of strange
> things happen, if you inherit, aggregate or MI such functions.
Generally speaking, I wouldn't agree. This is just about how python
does things, and it works very well, and is extremely usefull. Even JS
has setters and getters that can be inherited.
Specificly speaking about PHP, I would hope the implementations take
this into account and deal with them apropriately.
> When you are using constant names for such functions, at least
> defining them in your derived class will for sure overwrite and
> contain any inherited behaviour and you will know that you are
> clean and operate in a controlled namespace.
>
> We have had this with PHP 3 constructors running wild, we had
> this with PHP FI, 3 and 4 poisoning the global namespace, and we
> really should /not/ make this kind of mistake again.
These items are very far removed from problems in FI or 3, and don't use
the global namespace.
I guess being used to useing these features in other languages, I just
don't see a problem, as I don't see the issues you are talking about.
In fact, I think overloading has not been taken far enough, but that is
another story.
Shane
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
