Maybe I'm just confused (well, I'm always confused...) but if a Class
has multiple children, how the heck would PHP know which child:: to
call?...
On Sat, May 26, 2007 5:48 pm, Ken Stanley wrote:
> 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"
>
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
