Re: [PATCH] late binding for parent (and other options) - Was Re: [PHP-DEV] late static binding php6
| From: | Elizabeth Smith | Date: | Mon, 26 Nov 2007 13:08:30 +0000 |
| Subject: | Re: [PATCH] late binding for parent (and other options) - Was Re: [PHP-DEV] late static binding php6 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-33439@lists.php.net to get a copy of this message | ||
Alexey Zakhlestin wrote:
On 11/26/07, Mike Lively <m@digitalsandwich.com> wrote:People using a parent:: call in a class don't think of it as static, they think of it as call the class that this one extends, where as a explicit Class::method(); call means "call this static method", so they expect them to work differently.I have come up with three different patches that allow us to work around the issue of parent:: being considered an 'explicit class reference' and thus disallowing static:: to effectively used. The patches are against 5.3. I also have patches against HEAD but I was having problems getting run-tests.php to run against that code base (it would hang on the first test no matter which set of tests I ws running.) All three patches have different levels of intrusiveness to the engine and all three patches have been tested against (and pass) the existing lsb tests in Zend/tests/lsb_*.phpt 1.) lsb.parent-forwarding.patch This patch modifies the behavior of only parent:: to not change EG(called_class) to the parent of the current scope. With this change. <?php class A {I believe this first patch is the proper way to go. It feels "natural", "intuitive", etc. I also think this is the proper way to handle parent:: in a static context - I shudder to think of the number of "bogus" bug reports that'll pop up if lsb DOESN'T work this way.public static function test() { echo get_called_class()."\n"; }} class B extends A {public static function test() { parent::test(); }} A::test(); B::test(); ?> will output: A B It should be noticed that with this patch parent:: will always resolve to the parent of the current scope, it will just not make any changes to the called_scope (effectively)