[PATCH] Late Static Binding

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