__get_x() is simply a shortcut, I don't see how it can backfire on us in the overload framework. It is very helpful if you have a couple of variables that are more frequently accessed and you want to split up their processing from the rest. They are pretty much analogous to get/set property handlers in C#, except that those get converted to __prop_get/set() names by the compiler.
If you are worried about its interaction with aggregate(), there is no problem. Aggregate() will not import methods that start with '_'. On Mon, 08 Apr 2002, Kristian Köhntopp wrote: > As of now, this is just an unspecified bad feeling of mine. > I only can back up this with the two times we had special names > which were variable in PHP: Both attempts at them failed > horribly: > > - We had (have, until ZE 2, if I am not mistaken) variable > named constructors (ctors named after the class). These > had a number of design flaws in PHP 3, which were fixed in > PHP 4, at the cost of an overly complex ruleset for > constructor names. > > Had we chosen stable names for constructors, we'd gotten the > same effect with a single rule for ctor names. > > - We had (until very recently) variable names for imported > variables amidst our global namespace. We earned a number > of security problems due to admittedly stupid code, which > swayed the PTBs to finally disable registering globals by > default. > > I cannot come up with a bomb script right now, but I am > reasonably sure that __get_x() will backfire at some time > as well. > > Kristian -Andrei * On the keyboard of life, always keep one finger on the escape key. * -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
