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?
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?
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.
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.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
