late static binding

Hi all! I've been researching the current status of late static binding, and I came across this mailing list with a few topics on this subject. After doing the reading, I had a couple of questions that maybe one of the experienced parties involved could help clear up for me. Basically, I am wondering if anybody has tossed around the idea of having a scope of child::, just like there is one of parent:: (for the class that is inherited from) and self:: (the current class). I understand that the idea has been discussed about this:: or static::, but those two suggestions -- as fine as they are -- just seem counter intuitive. this has always been used in the same context as self::, but for instantiated objects, and static:: seems redundant (at least to me). Is there a reason why this:: would be preferred over child::? My second question on this topic would be how hard would it be to create a child scope in the Zend Engine? Since I am not a very experienced C programmer, this may be a naive question, but if Zend is smart enough to know who the inherited class object is, could it be much more difficult to know who did the inheriting? I mainly wanted to just add my Two Cents to the discussion, because as I get more and more into using PHP5 for OO programming, I am finding it more important to have late static binding. And, since I've seen the request made for examples of real-world use-cases, I am trying to build a set of classes that would allow me to work with the super globals without actually directly touching them. If we had something like a child:: scope, then I could write code that looked like this: class MyGlobals { static public function get($name) {

       // Each child would implement their own version of filter
       // that would handle the type of data that it has.
       child::filter(child::$global[$name];

       // Do common stuff here before returning value

} } class FilesGlobal extends MyGlobals { // This is so the parent class will know where to look for the information we need. Each class would have this declaration. static protected $global = $_FILES; static protected filter($value) {

       // Do file-related filtering here (i.e., validate filename is valid,

exists, etc) or throw an exception

       // on failure.

} } Instead, I have to write 9 separate classes, with each of the classes having all the same functions that are written almost exactly the same. So, for example, if I have 100 lines of code in one class, my overall set of classes would contain almost 800 lines of duplicate code. I hope this illustrates the appeal for this feature. It is a maintenance nightmare! :) I know it has been said by some that this functionality is rare, but I would like to say that the functionality was just never needed until recently. There are many cases that I can think of that this would be helpful, and if need be, I would be more than happy to write more examples. I think, however, that the above example shows a good situation for the parent class to be able to see the child class. Regardless of the direction taken with this issue, I would like thank all of the developers who have made PHP so great. :) - Ken -- It looked like something resembling white marble, which was probably what it was: something resembling white marble. -- Douglas Adams, "The Hitchhikers Guide to the Galaxy"