Everything

php

Home » Project » Newsgroups » php.internals » [PATCH] Late Static Binding »

[PATCH] Late Static Binding

php.internals

Mike Lively

20 years ago

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"

Lukas Smith

20 years ago

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

Marcus Börger

20 years ago

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();

?>>

Dmitry Stogov

20 years ago

Can I look into patch?

Dmitry.

> -----Original Message-----
> From: Marcus Boerger [mailto:helly@php.net]
> Sent: Wednesday, March 01, 2006 1:01 PM
> To: PHP-DEV
> Cc: Andi Gutmans; Mike Lively
> Subject: Re: [PHP-DEV] [PATCH] Late Static Binding
>
>
> 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-bin

ding-using-this-without-or-perhaps-with-a-different-name)

Marcus Börger

20 years ago

Hello Dmitry,

of course, what hinders you?
See original mail from Mike: http://news.php.net/php.internals/21991

regards
marcus

Wednesday, March 1, 2006, 12:51:51 PM, you wrote:

> Can I look into patch?

> Dmitry.

>> -----Original Message-----
>> From: Marcus Boerger [mailto:helly@php.net]
>> Sent: Wednesday, March 01, 2006 1:01 PM
>> To: PHP-DEV
>> Cc: Andi Gutmans; Mike Lively
>> Subject: Re: [PHP-DEV] [PATCH] Late Static Binding
>>
>>
>> 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-bin
> ding-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/zactivereco
>> rd-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.
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>

Best regards,
Marcus

Dmitry Stogov

20 years ago

I didn't look into the patch deep.
But I see one critical issue:

Patched PHP will modify zend_function->caller_scope at runtime.
This can break ZTS version and probaby opcode caches.
Storing runtime information in zend_function is bad decision.

Also the name "static" confusing me.
Because "self" behave more 'static' (and proper).

Thanks. Dmitry.

Marcus Börger

20 years ago

Hello Dmitry,

i guess there was enough discussion on the name and we do not want to
create another solwdown or BC by adding either slow string comparisions or
a new keyword. Anyway how can this affect ZTS version? We are working on
copies here as far as i know. And the information is touched at runtime
anyway since we are doing inheritance at runtime. The way out would be to
push the neccessary info on the stack which would be a big argument against
supporting late binding because that would be a major slowdown for php
everywhere and not only affect static method invocation.

best regards
marcus

Wednesday, March 1, 2006, 1:59:01 PM, you wrote:

Dmitry Stogov

20 years ago

1) I would very like to see some real example where "static" is necessary?

2) "static" is really bad name. I suggest "caller", Marcus thought about
"class".

3) I COMPLETELY DISAGREE TO ADD RUNTIME DATA INTO
zend_function/zend_op_array.
We can try to store "caller_scope" in execute_data.

Thanks. Dmitry.

Lukas Smith

20 years ago

Dmitry Stogov wrote:

> 1) I would very like to see some real example where "static" is necessary?

I think Mike illustrated this in his post. Or do you want a "real" world
example?

> 2) "static" is really bad name. I suggest "caller", Marcus thought about
> "class".

I dont really see an issue with calling the thing "static" considering
its about late static binding. Also AFAIK this name was agreed upong in
Paris. A meeting you also attended.

regards,
Lukas

Dmitry Stogov

20 years ago

> -----Original Message-----
> From: Lukas Smith [mailto:lsmith@php.net]
> Sent: Wednesday, March 01, 2006 5:50 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [PATCH] Late Static Binding
>
>
> Dmitry Stogov wrote:
> > 1) I would very like to see some real example where "static" is
> > necessary?
>
> I think Mike illustrated this in his post. Or do you want a
> "real" world
> example?

Yes I like not a sintetic test but real life example (singleton, factory or
something else).
(I tried to write generic singleton but it wasn't exelent.)

> > 2) "static" is really bad name. I suggest "caller", Marcus thought
> > about "class".
>
> I dont really see an issue with calling the thing "static"
> considering
> its about late static binding. Also AFAIK this name was
> agreed upong in
> Paris. A meeting you also attended.

Term "static" is already used for static methods. The conept of "late static
binding" doesn't exist in other languages, and nobody except authors will
understand that static::foo() is not a static method call.

Thanks. Dmitry.

Lukas Smith

20 years ago

Dmitry Stogov wrote:

> Yes I like not a sintetic test but real life example (singleton, factory or
> something else).
> (I tried to write generic singleton but it wasn't exelent.)

Yeah a singleton method that calls a factory method is a prime example.
Now if you want to inherit that class you will have to copy and paste
these methods.

Essentially whenever static methods meet inheritance you are quickly
likely to need late static binding. Sometimes you can hack around the
issue using reflection or requiring the user to pass the in the class
name he wants (like in a generic factory). But I do not think you can
even solve everything with the reflection API and its certainly not as
code efficient.

regards,
Lukas

Derick Rethans

20 years ago

On Wed, 1 Mar 2006, Dmitry Stogov wrote:

> Yes I like not a sintetic test but real life example (singleton, factory or
> something else).
> (I tried to write generic singleton but it wasn't exelent.)

I do have an example somewhere, but I have to find it again :)

regards,
Derick

Zeev Suraski

20 years ago

At 16:50 01/03/2006, Lukas Smith wrote:

>Dmitry Stogov wrote:
>>1) I would very like to see some real example where "static" is necessary?
>
>I think Mike illustrated this in his post. Or do you want a "real"
>world example?
>
>>2) "static" is really bad name. I suggest "caller", Marcus thought about
>>"class".
>
>I dont really see an issue with calling the thing "static"
>considering its about late static binding. Also AFAIK this name was
>agreed upong in Paris. A meeting you also attended.

I actually don't recall there was consensus on even adding this
feature in the Paris meeting, let alone how to name it.

Either way, implementation wise, as Dmitry said - storing runtime
information in zend_function or zend_op_array is simply out of the question.

Zeev

Lukas Smith

20 years ago

Zeev Suraski wrote:

> I actually don't recall there was consensus on even adding this feature
> in the Paris meeting, let alone how to name it.

To quote the meeting results as linked in Mike's original post:

1. We re-use the "static::" keyword to do runtime evaluation of statics.
2. Marcus prepares an implementation suggestion.

Atleast back then nobody who attended the meeting seemed to complain
about this seemingly definitive decision noted in Dericks summary.

Also note the notes on the discussion itself:

"Discussion: Currently there is no way do "runtime evaluating" of static
members so that we can call B::static2() from A::staticA() and this is a
useful feature. In order to implement this we need a new keyword to
allow for this. As we do not want to introduce yet another reserved word
the re-use of "static" was suggested for this."

Again it does not seem like there was any complaints about the
usefulness of the feature, yet both you and Dimitry attended the
meeting. So have you guys changed your mind on the need for this? Was
the summary incorrect?

It seems to me you are torpedoing a feature you agreed on as useful
because if technical concerns about one possible implementation.

regards,
Lukas

Jochem Maas

20 years ago

Zeev Suraski wrote:

> At 16:50 01/03/2006, Lukas Smith wrote:
>
>> Dmitry Stogov wrote:
>>
>>> 1) I would very like to see some real example where "static" is
>>> necessary?
>>
>>
>> I think Mike illustrated this in his post. Or do you want a "real"
>> world example?
>>
>>> 2) "static" is really bad name. I suggest "caller", Marcus thought about
>>> "class".
>>
>>
>> I dont really see an issue with calling the thing "static" considering
>> its about late static binding. Also AFAIK this name was agreed upong
>> in Paris. A meeting you also attended.
>
>
> I actually don't recall there was consensus on even adding this feature
> in the Paris meeting, let alone how to name it.

but there is a problem no? as illustrated by:
http://blog.joshuaeichorn.com/archives/2006/01/09/zactiverecord-cant-work/

I ran into this problem with Ard Biesheuvel with php5beta3. he considered
the fact that 'self' didn't resolve to the actual class being called a flaw,
I argee with him.

>
> Either way, implementation wise, as Dmitry said - storing runtime
> information in zend_function or zend_op_array is simply out of the
> question.

do you agree that 'a' feature is needed to satisfy the illustrated problem(s)?

kind regards,
Jochem

{simpletons idea ...}
rather than an alternative form of static method calling or a new class
related keyword, maybe a new magic constant would be sufficient? e.g.

__CCLASS__ (C for 'Called')

or
__OWNER__  (the class the 'owns' the method? [from the view point of the caller])

Derick Rethans

20 years ago

On Wed, 1 Mar 2006, Zeev Suraski wrote:

> I actually don't recall there was consensus on even adding this feature in the
> Paris meeting, let alone how to name it.

You didn't object to the meeting notes either (on this part). This is
the link to the notes again:
http://www.php.net/~derick/meeting-notes.html#late-static-binding-using-this-without-or-perhaps-with-a-different-name

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Jeff Moore

20 years ago

On Mar 1, 2006, at 9:37 AM, Dmitry Stogov wrote:

> 1) I would very like to see some real example where "static" is
> necessary?

Some use cases for late static binding, tested using self on 5.1.2:

1.  What class am I really?

class A {
static function myclass() {
return get_class();
}
}

class B extends A {}

echo A::myclass();  // A
echo B::myclass();  // also A


2. Template method pattern for static methods requires late binding:

class Common {
static function doit() {
self::header();
echo "The answer is 42";
self::footer();
}
// could be abstract
static function header() {}
static function footer() {}
}

class Html extends Common {
static function header() {
echo "<html>\n<body><B>";
}
static function footer() {
echo "</B></body>\n</html>";
}
}

echo html::doit();  // Sorry, no html


3.  Accessing a static property with late binding:

class A {
static protected $statprop = 'A';
static function getStatprop() {
return self::$statprop;
}
}

class B extends A {
static protected $statprop = 'B';
}

echo A::getStatprop(); // A
echo B::getStatprop(); // Also A


4. Static properties are hard to get at for anything other than the
explicit class name:

class A {
static public $iprop = 'A';
}

$class = 'A';
echo $class::$iprop;  // syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM


5. A (non-working) singleton base class implementation combining
multiple late binding issues:

class Singleton {
public $iprop = NULL;
static protected $instance;

static public function getInstance() {
if (!isset(self::$instance)) {
$class = get_class();
$obj = new $class();
self::configure($obj);
self::$instance = $obj;
}
return self::$instance;
}

static protected function configure($obj) {
}
}

class A extends Singleton {
static protected $instance;
static protected function configure($obj) {
$obj = 'A';
}
}

var_dump(A::getInstance()->iprop);  //NULL


This is an issue I would very much like to see resolved prior to 6.

Regards,

Jeff

Jeff Moore

20 years ago

On Mar 1, 2006, at 3:45 PM, Jeff Moore wrote:

>     static protected function configure($obj) {
>         $obj = 'A';
>     }

Oops.  That should be $obj->iprop = 'A'.

Dmitry Stogov

20 years ago

Hi Jeff,

Your examples 1-4 are bad.
They snould use non-static methodos.

Example (5) make sense, but it is not exelent (I did the same :), because
"A" MUST be child of Singleton and it must declare special property.

BTW: generic singletons can be implemented with one very simple function

function single_instance($class_name) {
static $instances = array();
return (isset($instances[$class_name])) ?  $instances[$class_name] :
($instances[$class_name] = new $class_name);
}

Thanks. Dmitry.

David Zülke

20 years ago

> Your examples 1-4 are bad.
> They snould use non-static methodos.

Wrong. Example: Singletons where you could just do "MyObj extends
SingletonObj" without having to re-implement getInstance().

- David

Andi Gutmans

20 years ago

At 06:37 AM 3/1/2006, Dmitry Stogov wrote:

>1) I would very like to see some real example where "static" is necessary?

It's needed when you implement a convention based system where the
name of the Class has a meaning. For example in an OORDBMS mapping
system, the name of the class could be the table name.

>2) "static" is really bad name. I suggest "caller", Marcus thought about
>"class".

Yeah static is very confusing and I think it's a bad idea.

I'm trying to think what a non-confusing way would be. Some ideas would be:
a) using "class" e.g. class::method()
b) change behavior of self:: to always be "virtual" and have people
use class_name::method()

Any other ideas? I think we should solve this issue but let's
brainstorm and find the right way, both syntax wise and
implementation wise (without breaking opcode caches).

Andi

Dmitry Stogov

20 years ago

> -----Original Message-----
> From: Andi Gutmans [mailto:andi@zend.com]
> Sent: Thursday, March 02, 2006 5:51 AM
> To: Dmitry Stogov; 'Marcus Boerger'; 'Mike Lively'
> Cc: 'PHP-DEV'
> Subject: RE: [PHP-DEV] [PATCH] Late Static Binding
>
>
> At 06:37 AM 3/1/2006, Dmitry Stogov wrote:
> >1) I would very like to see some real example where "static" is
> >necessary?
>
> It's needed when you implement a convention based system where the
> name of the Class has a meaning. For example in an OORDBMS mapping
> system, the name of the class could be the table name.
>
> >2) "static" is really bad name. I suggest "caller", Marcus thought
> >about "class".
>
> Yeah static is very confusing and I think it's a bad idea.
>
> I'm trying to think what a non-confusing way would be. Some
> ideas would be:
> a) using "class" e.g. class::method()
> b) change behavior of self:: to always be "virtual" and have people
> use class_name::method()
>
> Any other ideas?

static::foo()

class::foo()

caller::foo()

owner::foo()

Thanks. Dmitry.

Bart de Boer

20 years ago

final::foo();

Dmitry Stogov wrote:

Jeff Moore

20 years ago

On Mar 1, 2006, at 9:50 PM, Andi Gutmans wrote:

> Yeah static is very confusing and I think it's a bad idea.
>
> I'm trying to think what a non-confusing way would be. Some ideas
> would be:
> a) using "class" e.g. class::method()
> b) change behavior of self:: to always be "virtual" and have people
> use class_name::method()
>
> Any other ideas? I think we should solve this issue but let's
> brainstorm and find the right way, both syntax wise and implementation
> wise (without breaking opcode caches).

To me, the ideal solution would be to use  __class__ for the early
binding case and self for the late binding case.  Are there any
situations now where __class__ and self aren't the same class?  To me
__class__ and self are nearly redundant and it is the late binding that
is completely missing.

early:
__class__::method()
__class__::$property
__class__::constant

late:
self::method()
self::$property
self::constant

That seems very consistent to me and easy to explain.

Unfortunately, the problem with making self late binding is that that
there are potential BC breaks.  Is that possibility on the table?  I
definitely think that self makes more sense as the late binding
keyword, but I think that ship has sailed.  Please correct me if I am
wrong.

I didn't like static at first, either, but  it grew on me after a
while.  Self is already confusing.  Without redefining it, any approach
(including doing nothing) is going to involve a degree of confusion.

Regards,

Jeff

Derick Rethans

20 years ago

On Thu, 2 Mar 2006, Jeff Moore wrote:

> Unfortunately, the problem with making self late binding is that that there
> are potential BC breaks.  Is that possibility on the table?

I don't think we should break any BC over this.

Derick

Mike Lively

20 years ago

On Wed, 2006-03-01 at 17:37 +0300, Dmitry Stogov wrote:

> 1) I would very like to see some real example where "static" is necessary?
>
> 2) "static" is really bad name. I suggest "caller", Marcus thought about
> "class".
>
> 3) I COMPLETELY DISAGREE TO ADD RUNTIME DATA INTO
> zend_function/zend_op_array.
> We can try to store "caller_scope" in execute_data.
>
> Thanks. Dmitry.
>

Rewrote the patch to use execute_data to store caller_scope. I have not
renamed any functions or keywords (still using static::) as I did not
see any consensus on that yet.

Please review the implementation of caller_scope and I can take care of
the naming issues when names are decided on.

patch attached and also available at
http://test.ft11.net/_mlively/late-static-binding.patch

It would be nice if the patch in PAT could be changed to reference this
new version if the appropriate people have time.

Andi Gutmans

20 years ago

This patch is a bit rough. I'll try and think if there's a more elegant way.

Andi

At 01:06 PM 3/8/2006, Mike Lively wrote:

David Zülke

20 years ago

I'd still say we make it "this". It's reasonable and consistent.

- David

Am 09.03.2006 um 01:13 schrieb Andi Gutmans:

Dmitry Stogov

20 years ago

Hi Mike,

I finally found a day to look into your patch and make it work in all (may
be I forgot something) cases.

Improved patch and test cases are attached.

I still don't like name - "static",
and I am not sure that this concept is necessary for PHP.

Thanks. Dmitry.

Jochem Maas

20 years ago

Dmitry Stogov wrote:

> Hi Mike,
>
> I finally found a day to look into your patch and make it work in all (may
> be I forgot something) cases.
>
> Improved patch and test cases are attached.
>
> I still don't like name - "static",

as long as it gets in, I'll love you [all] whatever name you give it! :-)

> and I am not sure that this concept is necessary for PHP.

every halfassed phper doing OO in php5 would then love to know
how Zend intends implement something like:

Person::findAll( $myFilter )

... with out having to actually implement a findAll method in
the Person class (i.e. using a single generic findAll method defined
in whatever DataObject class Person is derived from (ZDataObject IIRC).

seriously; if there is a clean way of doing it without the introduction
of a static late binding keyword/token (forgive me if mine use of terminology is off)
then please put us out of our misery (or point me to the place I can learn and I'll
put myself out of my misery ;-) - I've been struggling to find a decent
solution to this since php5 was in beta and I regularly search around to see
how other are coping with this issue  - in almost all cases it turns out to be
something like:

$peeps = Person::findAll('Person', $myFilter)

or

$p = new Person; $peeps = $p->findAll( $myFilter );

niether of which really do it for me, and in the second example it feels
like some OO principles are being thoroughly raped.

rgds,
Jochem

Mike Lively

20 years ago

I took a quick glance through it and it mostly makes sense to me. If
anyone could clear up a question when time permits: I don't fully
understand why both executor_globals and and execute_data are used to
store the caller_scope pointer.

I almost had a finished another patch myself using EG() but I had to
take a break to pay my bills :/. Thanks for looking at this Dmitry. I
will go ahead and put together a more exhaustive use case for this over
the weekend.

Mike Lively

Dmitry Stogov wrote:

Lukas Smith

20 years ago

Dmitry Stogov wrote:

> Patched PHP will modify zend_function->caller_scope at runtime.
> This can break ZTS version and probaby opcode caches.
> Storing runtime information in zend_function is bad decision.

maybe stating the obvious here .. but opcode caches are important to
everybody on this list i am sure .. so i think you do not have to worry
that a majority would favor a solution that puts them in a bind.

here is hoping that we can find an opcode cache compatible solution to
get this useful feature in.

regards,
Lukas

Jeff Moore

20 years ago

On Feb 23, 2006, at 5:06 PM, Mike Lively wrote:

> 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

Dmitry Stogov

20 years ago

Agree.

The following constructs should use the same <name>:<name>::foo()
get_<name>_calss()