On Thu, 2004-05-13 at 11:41, Gregory wrote: > Rudy Metzger wrote: > > >Although you are correct with your explanations to better use methods > >and private/protected attributes, this is not the core of the problem. > >The problem is that self:: always refers to the current class (A or B or > >C), so if you would call self::Something() in C it would not access > >A::Something(). The same counts for parent::. It only accesses the > >instance DIRECTLY below. > > > >An yes, A::$myInstance is easy to remember. But what if I put it into B > >at some later points, because I am shifting around class structure (for > >whatever well thought out reason)? Then I would have to change all > >occurances of A::$myInstance, which I really do not want. > > > >I think a good solution for this would be to modify parent::, that it > >does not only access its DIRECT superclass, but goes up the hierarchy > >until the static variable is found. > > > >Cheerio > >/rudy > > > > > I understand what you want to do (or to avoid). Yes, by directly access > static > functions/properties, class hierarchy becomes useless and doesn't allow > a complete > modularity anymore. > Then the parent:: keyword must go up until a matching function/variable > is found. > You're totally right on this. > > Greg
Actually only modifying parent:: does not solve it, because the static could be in self:: - thus either self:: also has to go up the hierarchy or a new keyword (static::, class::) is invented. Or even better: Why not allow this:: to access static variables, e.g. this::$myInstance. Would make the most sense, i guess. Cheerio /rudy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
