Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29919
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain l-i-e.com from 67.139.134.202 cause and error)
Message-ID: <56275.216.230.84.67.1180484964.squirrel@www.l-i-e.com>
In-Reply-To: <c70e053d0705261548v63c111a1qf9bfae78534b27da@mail.gmail.com>
References: <c70e053d0705261548v63c111a1qf9bfae78534b27da@mail.gmail.com>
Date: Tue, 29 May 2007 19:29:24 -0500 (CDT)
To: "Ken Stanley" <dohpaz@gmail.com>
Cc: internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] late static binding
From: ceo@l-i-e.com ("Richard Lynch")

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?