Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29821
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain digitalsandwich.com does not designate 68.230.241.41 as permitted sender)
Message-ID: <4658D0CB.9070901@digitalsandwich.com>
Date: Sat, 26 May 2007 17:28:59 -0700
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Ken Stanley <dohpaz@gmail.com>
CC:  internals@lists.php.net
References: <c70e053d0705261548v63c111a1qf9bfae78534b27da@mail.gmail.com>
In-Reply-To: <c70e053d0705261548v63c111a1qf9bfae78534b27da@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] late static binding
From: m@digitalsandwich.com (Mike Lively)

Ken Stanley wrote:
> 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::?
It appears that all you are suggesting that is different from what has 
been discussed previously is purely syntactical. In that regard I would 
have to say that while neither this:: or static:: are jaw-droppers, 
child:: seems somewhar counter-intuitive to me. From a purely semantical 
standpoint, parent:: and self:: work because there is only ever one. On 
the other hand it seems like it would be somewhat confusing to a 
developer not aware of the syntax to figure out what child:: would mean. 
A class could have 'n' number of children and while I realize that it is 
not really what the late static binding is about it still seems awkward.
> 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?
There is (with as much time as has passed this may be more accurately 
represented as was) a working patch to implement late static binding. I 
did some early work on it and it was then rewritten to store the 
required information in the proper places. If I recall correctly it was 
left at the point of someone needing to determine the performance impact 
of the patch and come up with solid use cases.
> 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.
The term "late static binding" is slightly more rare than the 
functionality itself. There are a few other languages that implement 
similar concepts.

I do know the ball was left firmly in my court on this issue last year 
and I also know that there has been continued interest from the php 
userbase about such a feature. If there is still support for it among 
the core developers I would be interested in taking up the issue again, 
reviewing and ensuring the most recent patch is still adequate as it 
relates to head, and determining the performance impact of the patch.

-- 
Mike Lively
http://www.digitalsandwich.com