I have finished a patch that implements a working version of late static
binding.
I used the notes from the Paris PDM as my guidelines for implementation.
(http://www.php.net/~derick/meeting-notes.html#late-static-binding-using-this-without-or-perhaps-with-a-different-name) As requested in the notes I reused 'static::'. I also wrote a few tests not only to test the new functionality but also to make sure 'static' can't be inherited or extended.
I also added a new function get_caller_class() which returns the name of
the class that static:: would represent.
(borrowing from PDM notes)
In php5.* the following script outputs "A::static2":
<?php
class A {
static function staticA() {
self::static2();
}
static function static2() {
echo "A::static2\n";
}
}
class B extends A {
static function static2() {
echo "B::static2\n";
}
}
B::staticA();
?>
This has somewhat recently been highlighted by different developers to
be somewhat problematic behavior in creating user friendly APIs. If you
want to see a possible use for it you need look no further than the
example ZActiveRecord API that was used in their webcast with php|arch.
(http://blog.joshuaeichorn.com/archives/2006/01/09/zactiverecord-cant-work/) Currently the code laid out there is impossible short of some ugly use of debug_backtrace() and file parsing :/. This patch of course would allow that kind of code too exist.
In a small example based on the one I gave earlier you could change the
code too the following and have it print "B::static2":
<?php
class A {
static function staticA() {
static::static2();
}
static function static2() {
echo "A::static2\n";
}
}
class B extends A {
static function static2() {
echo "B::static2\n";
}
}
B::staticA();
?>
As far as current userland code impact, there is very little as far as I
can tell. No keywords have been added, just another use for an existing
one. No changes were made to self:: or parent:: so the change should be
pretty transparent. The only thing that I see remotely causing any
issues would be the new function (get_caller_class().) I added that just
to complete the set so to speak.
Mike Lively (ds- on irc.efnet.org)
"Our Schwartz is bigger than yours"
Mike Lively wrote:
As far as current userland code impact, there is very little as far as I
can tell. No keywords have been added, just another use for an existing
one. No changes were made to self:: or parent:: so the change should be
pretty transparent. The only thing that I see remotely causing any
issues would be the new function (get_caller_class().) I added that just
to complete the set so to speak.
I will try to find time to test this patch. But it will be another few
days before I have time to revive my linux vmware instance.
However I just wanted to mention that I would really love to see this
feature in php 6 or even php 5.2.x
regards,
Lukas
Hello internals,
it looks like either nobody objects or nobody has interest. Either way
i tested the patch and worked helped it a bit and it looks good, doesn't
affect anything else and doesn't show a single problem in valgrind. So If
noone objects i will commit this next week.
regards
marcus
special mail to andi :-)
Thursday, February 23, 2006, 11:06:02 PM, you wrote:
I have finished a patch that implements a working version of late static
binding.
I used the notes from the Paris PDM as my guidelines for implementation.
(http://www.php.net/~derick/meeting-notes.html#late-static-binding-using-this-without-or-perhaps-with-a-different-name)
As requested in the notes I reused 'static::'. I also wrote a few tests
not only to test the new functionality but also to make sure 'static' can't be inherited or extended.
I also added a new function get_caller_class() which returns the name of
the class that static:: would represent.
(borrowing from PDM notes)
In php5.* the following script outputs "A::static2":
<?php
class A {
static function staticA() {
self::static2();
}
static function static2() { echo "A::static2\n"; } }
class B extends A { static function static2() { echo "B::static2\n"; } }
B::staticA();
?>>
This has somewhat recently been highlighted by different developers to
be somewhat problematic behavior in creating user friendly APIs. If you
want to see a possible use for it you need look no further than the
example ZActiveRecord API that was used in their webcast with php|arch.
(http://blog.joshuaeichorn.com/archives/2006/01/09/zactiverecord-cant-work/)
Currently the code laid out there is impossible short of some ugly use of
debug_backtrace()and file parsing :/. This patch of course would allow that kind of code too exist.
In a small example based on the one I gave earlier you could change the
code too the following and have it print "B::static2":
<?php
class A {
static function staticA() {
static::static2();
}
static function static2() { echo "A::static2\n"; } }
class B extends A { static function static2() { echo "B::static2\n"; } }
B::staticA();
?>>
As far as current userland code impact, there is very little as far as I
can tell. No keywords have been added, just another use for an existing
one. No changes were made to self:: or parent:: so the change should be
pretty transparent. The only thing that I see remotely causing any
issues would be the new function (get_caller_class().) I added that just
to complete the set so to speak.
I also added a new function get_caller_class() which returns the name
of
the class that static:: would represent.
I find get_caller_class() a bit confusing because it introduces new
terminology (caller). May I suggest adding:
get_self_class() // corresponds to self
get_static_class() // corresponds to static
This already exists:
get_parent_class() // corresponds to parent
What should get_class() return inside of a static method? I frankly
don't care, because I would always use get_self_class() or
get_static_class() so that the meaning was explicit.
Thanks for the patch, I'm excited about this one. Oh, using the key
word static doesn't bother me at all.
Best Regards,
Jeff