# late static binding

- Thread: https://externals.io/message/29820
- Original archive: https://news-web.php.net/php.internals/29820
- Started by Ken Stanley on 2007-05-26T22:48:56+00:00
- Messages: 19
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #29820 — Ken Stanley — 2007-05-26T22:48:56+00:00

URL: https://externals.io/message/29820#29820

Hi all!

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::?

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?

I mainly wanted to just add my Two Cents to the discussion, because as I get
more and more into using PHP5 for OO programming, I am finding it more
important to have late static binding.

And, since I've seen the request made for examples of real-world use-cases,
I am trying to build a set of classes that would allow me to work with the
super globals without actually directly touching them. If we had something
like a child:: scope, then I could write code that looked like this:

class MyGlobals
{
    static public function get($name)
    {
        // Each child would implement their own version of filter
        // that would handle the type of data that it has.
        child::filter(child::$global[$name];

        // Do common stuff here before returning value
    }
}

class FilesGlobal extends MyGlobals
{
    // This is so the parent class will know where to look for the
information we need. Each class would have this declaration.
    static protected $global = $_FILES;

    static protected filter($value)
    {
        // Do file-related filtering here (i.e., validate filename is valid,
exists, etc) or throw an exception
        // on failure.
    }
}

Instead, I have to write 9 separate classes, with each of the classes having
all the same functions that are written almost exactly the same. So, for
example, if I have 100 lines of code in one class, my overall set of classes
would contain almost 800 lines of duplicate code. I hope this illustrates
the appeal for this feature. It is a maintenance nightmare! :)

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.

Regardless of the direction taken with this issue, I would like thank all of
the developers who have made PHP so great. :)

- Ken
-- 
It looked like something resembling white marble, which was
probably what it was: something resembling white marble.
                -- Douglas Adams, "The Hitchhikers Guide to the Galaxy"

---

## #29821 — Mike Lively — 2007-05-27T00:28:59+00:00

URL: https://externals.io/message/29820#29821 · In reply to: #29820

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

---

## #29823 — Ken Stanley — 2007-05-27T02:07:13+00:00

URL: https://externals.io/message/29820#29823 · In reply to: #29821

>
> 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.


Yes, I was asking purely for syntactical reasons, but you raise a very
interesting point that I did not take wholly into consideration. While my
example was meant for multiple children, I did not realize how much more
complicated that would become.

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.


I hope the support is still there, and if you do release a patch for it, I
would be more than happy to help test it.

Thank you for your time in responding to my questions. You have definately
given me some food for thought. :)

-- 
It looked like something resembling white marble, which was
probably what it was: something resembling white marble.
                -- Douglas Adams, "The Hitchhikers Guide to the Galaxy"

---

## #29826 — Bart de Boer — 2007-05-27T09:48:54+00:00

URL: https://externals.io/message/29820#29826 · In reply to: #29821

This subject has some correlation with my previous suggestion. Except I 
totally forgot about the "late static binding" discussion.

I'd like to give another real life example. This is an oversimplified 
version of what I'd currently like to do (without a bunch of workarounds):


<?php

class DataTableCollection {

	public function getItems() {

		$typeOff = this::$typeOf;
		$sql = 'SELECT * FROM ' . $typeOff::$tableName;
		...

		// or like suggested by Arnold Daniels:

		$sql = 'SELECT * FROM ' . ${this::$typeOf}::$tableName;
		...

	}

}

class DataTableItem {}



class Users extends DataTableCollection {

	static $typeOf = "User";

}

class User extends DataTableItem {

	static $tableName = "TBL_USERS";
	static $primaryKey = "USER_ID";
	static $foreignKeys = array('ADDRESS_ID' => 'Address');

}



$users = new Users();

foreach ($users as $user) {
	$user->doSomething();
}

?>


For this to work properly, you can imagine that it would need to be 
possible to dynamically access static variables all over the place from 
within different scopes. There are probably other approaches, but I 
thought this would be a very elegant one if it were possible. :)


-- Bart



Mike Lively wrote:
> Ken Stanley wrote:
> > […]
> 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.
> > […]
> 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.
> > […]
> 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.

---

## #29849 — Stanislav Malyshev — 2007-05-28T19:58:49+00:00

URL: https://externals.io/message/29820#29849 · In reply to: #29820

> 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

Well, this exactly name makes little sense, since class has only one 
self and one parent, but can have many children, so child:: does not 
uniquely identify the context. However, the idea of having dynamic scope 
that refers to the class which was mentioned during the static call was 
indeed raised a number of times. The problem there is that since 
currently the engine does not preserve that class scope, it is not 
accessible inside the static call.

> 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

I don't really understand - what is "child scope"?

> 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?

Yes, it could and it is. There's an unique link from child to parent, 
but there's no any link from parent to child, neither this link is 
possible since parent can have many children which could come into 
existence at any time during the lifecycle of the script.
-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

---

## #29919 — Richard Lynch — 2007-05-30T00:29:24+00:00

URL: https://externals.io/message/29820#29919 · In reply to: #29820

Maybe I'm just confused (well, I'm always confused...) but if a Class
has multiple children, how the heck would PHP know which child:: to
call?...


> Hi all!
>
> 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::?
>
> 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?
>
> I mainly wanted to just add my Two Cents to the discussion, because as
> I get
> more and more into using PHP5 for OO programming, I am finding it more
> important to have late static binding.
>
> And, since I've seen the request made for examples of real-world
> use-cases,
> I am trying to build a set of classes that would allow me to work with
> the
> super globals without actually directly touching them. If we had
> something
> like a child:: scope, then I could write code that looked like this:
>
> class MyGlobals
> {
>     static public function get($name)
>     {
>         // Each child would implement their own version of filter
>         // that would handle the type of data that it has.
>         child::filter(child::$global[$name];
>
>         // Do common stuff here before returning value
>     }
> }
>
> class FilesGlobal extends MyGlobals
> {
>     // This is so the parent class will know where to look for the
> information we need. Each class would have this declaration.
>     static protected $global = $_FILES;
>
>     static protected filter($value)
>     {
>         // Do file-related filtering here (i.e., validate filename is
> valid,
> exists, etc) or throw an exception
>         // on failure.
>     }
> }
>
> Instead, I have to write 9 separate classes, with each of the classes
> having
> all the same functions that are written almost exactly the same. So,
> for
> example, if I have 100 lines of code in one class, my overall set of
> classes
> would contain almost 800 lines of duplicate code. I hope this
> illustrates
> the appeal for this feature. It is a maintenance nightmare! :)
>
> 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.
>
> Regardless of the direction taken with this issue, I would like thank
> all of
> the developers who have made PHP so great. :)
>
> - Ken
> --
> It looked like something resembling white marble, which was
> probably what it was: something resembling white marble.
>                 -- Douglas Adams, "The Hitchhikers Guide to the
> Galaxy"
>


-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

---

## #29955 — Jochem Maas — 2007-05-30T14:54:56+00:00

URL: https://externals.io/message/29820#29955 · In reply to: #29919

Richard Lynch wrote:
> Maybe I'm just confused (well, I'm always confused...) but if a Class
> has multiple children, how the heck would PHP know which child:: to
> call?...

the use of the name 'child' is very confusing, I would prefer 'super' or 'static' ...
regardless the concept is actually quite simple:

interface DOInfo {
	static function getTableName();
}

abstract class DataObject implements DOInfo {
	static function findRange() {
		$table = super::getTableName();
		return $foo; // $foo is a collection of whatever (e.g. Product objects)
	}

	static function getTableName() {
		throw new Exception('be a dear and implement '.__METHOD__.' in your subclass'); }

	}

class Product extends DataObject {
	static function getTableName() { return 'PRODS'; }
}

$products = Product::findRange();

excuse me if I've just committed a grave sin against the OO Codex in writing something
that either isn't 'correct' or is syntactically incorrect according to the current
state of php - hopefully the idea is clear anyway.

> > […]

---

## #29982 — Bart de Boer — 2007-05-31T07:05:09+00:00

URL: https://externals.io/message/29820#29982 · In reply to: #29955

static function getTableName() { return 'PRODS'; }

What a great idea! You can just do:

$tableName = $this->getTableName();

...from within the base class. No need for static:: or super:: keywords 
anymore... It may be not as elegant as having a special keyword for 
it... But, for now, this approach would partially make my code a bit 
more elegant... Thanx!

Now, all I would still like to be able to do is:

$className::getTableName();





Jochem Maas wrote:
> Richard Lynch wrote:
> > […]
> 
> the use of the name 'child' is very confusing, I would prefer 'super' or 'static' ...
> regardless the concept is actually quite simple:
> 
> interface DOInfo {
> 	static function getTableName();
> }
> 
> abstract class DataObject implements DOInfo {
> 	static function findRange() {
> 		$table = super::getTableName();
> 		return $foo; // $foo is a collection of whatever (e.g. Product objects)
> 	}
> 
> 	static function getTableName() {
> 		throw new Exception('be a dear and implement '.__METHOD__.' in your subclass'); }
> 
> 	}
> 
> class Product extends DataObject {
> 	static function getTableName() { return 'PRODS'; }
> }
> 
> $products = Product::findRange();
> 
> excuse me if I've just committed a grave sin against the OO Codex in writing something
> that either isn't 'correct' or is syntactically incorrect according to the current
> state of php - hopefully the idea is clear anyway.
> 
> > […]

---

## #29980 — Bart de Boer — 2007-05-31T07:06:58+00:00

URL: https://externals.io/message/29820#29980 · In reply to: #29955

static function getTableName() { return 'PRODS'; }

What a great idea! You can just do:

$tableName = $this->getTableName();

...from within the base class. No need for static:: or super:: keywords 
anymore... It may be not as elegant as having a special keyword for 
it... (Or if this is the intended solution with PHP)... But, for now, 
this approach would partially make my code a bit more elegant... Thanx!

Now, all I would still like to be able to do is:

$className::getTableName();





Jochem Maas wrote:
> Richard Lynch wrote:
> > […]
> 
> the use of the name 'child' is very confusing, I would prefer 'super' or 'static' ...
> regardless the concept is actually quite simple:
> 
> interface DOInfo {
> 	static function getTableName();
> }
> 
> abstract class DataObject implements DOInfo {
> 	static function findRange() {
> 		$table = super::getTableName();
> 		return $foo; // $foo is a collection of whatever (e.g. Product objects)
> 	}
> 
> 	static function getTableName() {
> 		throw new Exception('be a dear and implement '.__METHOD__.' in your subclass'); }
> 
> 	}
> 
> class Product extends DataObject {
> 	static function getTableName() { return 'PRODS'; }
> }
> 
> $products = Product::findRange();
> 
> excuse me if I've just committed a grave sin against the OO Codex in writing something
> that either isn't 'correct' or is syntactically incorrect according to the current
> state of php - hopefully the idea is clear anyway.
> 
> > […]

---

## #30008 — Richard Lynch — 2007-05-31T20:37:46+00:00

URL: https://externals.io/message/29820#30008 · In reply to: #29955

> Richard Lynch wrote:
> > […]
>
> the use of the name 'child' is very confusing, I would prefer 'super'
> or 'static' ...
> regardless the concept is actually quite simple:
>
> interface DOInfo {
> 	static function getTableName();
> }
>
> abstract class DataObject implements DOInfo {
> 	static function findRange() {
> 		$table = super::getTableName();
> 		return $foo; // $foo is a collection of whatever (e.g. Product
> objects)
> 	}
>
> 	static function getTableName() {
> 		throw new Exception('be a dear and implement '.__METHOD__.' in your
> subclass'); }
>
> 	}
>
> class Product extends DataObject {
> 	static function getTableName() { return 'PRODS'; }
> }
>
> $products = Product::findRange();
>
> excuse me if I've just committed a grave sin against the OO Codex in
> writing something
> that either isn't 'correct' or is syntactically incorrect according to
> the current
> state of php - hopefully the idea is clear anyway.

You may think this is "quite simple" but I've skimmed it several times
and have no idea what the heck is going on...

I do know that 'super', to me, implies superclass which PHP just calls
parent:: so I don't like that either.

If it's just calling the static method of the interface parent-y
thingie, I dunno, maybe just static:: would work?

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

---

## #30024 — Bart de Boer — 2007-06-01T07:14:51+00:00

URL: https://externals.io/message/29820#30024 · In reply to: #30008

Richard Lynch wrote:
> 
> > […]
> 
> You may think this is "quite simple" but I've skimmed it several times
> and have no idea what the heck is going on...
> 
> I do know that 'super', to me, implies superclass which PHP just calls
> parent:: so I don't like that either.
> 
> If it's just calling the static method of the interface parent-y
> thingie, I dunno, maybe just static:: would work?
> 


static:: seems weird because it implies otherkeyword:: is not static.

Perhaps we should forget about the whole keyword and just allow objects 
to access its static members like any other member? It works like that 
for static functions too. Why not let it act that way for static variables?:

<?php

class Base
{
	function __construct() {
		echo $this->var;
	}
}

class Child extends Base
{
	static $var = "howdy";
}

?>

Seems to me all the PHP engine would have to do is create an object 
member with the same name which references the static variable of the 
class? But then I'm no PHP engine expert. :)

-- Bart

---

## #30028 — Ken Stanley — 2007-06-01T12:43:13+00:00

URL: https://externals.io/message/29820#30028 · In reply to: #30024

First of all, thank you to everybody who has responded to my (silly)
questions; you have made this subject a lot more understandable. :)

static:: seems weird because it implies otherkeyword:: is not static.


I think the point that was made from the other posters was that child:: was
way too confusing because it implied something that just goes way beyond the
scope of what the PHP can and cannot do. Without any other  reasonable
alternative to the keyword, I have to agree that static:: is the best
candidate for the job. As for parent/self:: and even static::, what makes
them static is the scope resolution operator (::), not their name. Their
name just implies the context in which they are to be used.

Anyways, I don't think there is a perfect solution that everybody would just
love. It appears that this is a very difficult subject.

Perhaps we should forget about the whole keyword and just allow objects
> to access its static members like any other member? It works like that
> for static functions too. Why not let it act that way for static
> variables?:


I would have to disagree with you on this subject. The whole point of having
a static model is the ability to access members of classes without having to
instantiate them. ClassName::classMember is completely different than
$className->classMember. Using the former means that you do not necessarily
have an instantiated object of ClassName, but in the latter it is implied
that you do. I would think that using $this::classMember in the wrong place
could lead to some very troubling errors at run-time.

-- 
It looked like something resembling white marble, which was
probably what it was: something resembling white marble.
                -- Douglas Adams, "The Hitchhikers Guide to the Galaxy"

---

## #30034 — Bart de Boer — 2007-06-01T22:57:19+00:00

URL: https://externals.io/message/29820#30034 · In reply to: #30028

Ken Stanley wrote:

> As for parent/self:: and even static::, what makes
> them static is the scope resolution operator (::), not their name. 
> Their name just implies the context in which they are to be used.
> 

That's right. And that's exactly why it's such a bad idea to call it 
static::. It's the scope resolution operator which already makes them 
static, not their name. (I'm sorry for catching you on your words ;) )


> > […]
> 
> I would have to disagree with you on this subject. The whole point of 
> having
> a static model is the ability to access members of classes without 
> having to
> instantiate them.
>

That's not right. Accessing the child class would only be possible from 
within an instantiated object. Unlike parent::, you will never be able 
to use static:: in a purely static context. Imagine there are multiple 
child classes which all inherit from the same base class. If there's no 
instance, PHP won't be able to know which child class to target with 
child::, static:: or whateverkeyword:: since it can be any one of those 
child classes.


> ClassName::classMember is completely different than
> $className->classMember. Using the former means that you do not necessarily
> have an instantiated object of ClassName, but in the latter it is implied
> that you do. I would think that using $this::classMember in the wrong place
> could lead to some very troubling errors at run-time.
>

Since there's no use for it in a static context anyway, I think 
static::, child:: or whateverkeyword:: would be confusing for 
developers. Since this would only work from withing an instance, I 
thought it might be a better idea to make static members accessible 
through $this->. (I think I even expected this to work when I first 
found out it didn't ;) )

---

## #30036 — Ken Stanley — 2007-06-02T02:49:33+00:00

URL: https://externals.io/message/29820#30036 · In reply to: #30034

>
> That's right. And that's exactly why it's such a bad idea to call it
> static::. It's the scope resolution operator which already makes them
> static, not their name. (I'm sorry for catching you on your words ;) )


I agree that it is not the best name, just not as bad as some of the others.
:)

That's not right. Accessing the child class would only be possible from
> within an instantiated object. Unlike parent::, you will never be able
> to use static:: in a purely static context. Imagine there are multiple
> child classes which all inherit from the same base class. If there's no
> instance, PHP won't be able to know which child class to target with
> child::, static:: or whateverkeyword:: since it can be any one of those
> child classes.


I agree. When I made my first post, I had not made this consideration.

Since there's no use for it in a static context anyway, I think
> static::, child:: or whateverkeyword:: would be confusing for
> developers. Since this would only work from withing an instance, I
> thought it might be a better idea to make static members accessible
> through $this->. (I think I even expected this to work when I first
> found out it didn't ;) )
>

For the sake of argument, let's say that php did this; then anytime you
needed this functionality, it would only be available in instantiated
objects. That is a pretty limiting feature, and to me it would be
meaningless. I say it is meaningless because if you instantiate an object,
you can do a set up in the constructor to tell the parent what it needs to
know without the late static binding. It may not be the perfect solution,
but it would also be very far from a kludge at the same time. But, on the
huge downside, this functionality would be lost on static methods and
properties, where I feel it would be at the greatest benefit.

Honestly, I admit that I am not as smart as these guys who built -- and
continue to build -- PHP. I personally have no further suggestions on what
to do about this problem, but I want thank everybody for their time -- and
indulgences -- in listening to me and educating me. I will continue to watch
this forum so I can learn more. Have a great weekend everybody! :)

-- 
It looked like something resembling white marble, which was
probably what it was: something resembling white marble.
                -- Douglas Adams, "The Hitchhikers Guide to the Galaxy"

---

## #30071 — Jochem Maas — 2007-06-05T15:17:40+00:00

URL: https://externals.io/message/29820#30071 · In reply to: #30034

Bart de Boer wrote:
> Ken Stanley wrote:
> 

...

> That's not right. Accessing the child class would only be possible from
> within an instantiated object. Unlike parent::, you will never be able
> to use static:: in a purely static context. Imagine there are multiple
> child classes which all inherit from the same base class. If there's no
> instance, PHP won't be able to know which child class to target with
> child::, static:: or whateverkeyword:: since it can be any one of those
> child classes.

huh??? the 'child' class would refer to the class that was actually named
when then call to the method was made (thats what late static binding means,
does it not?):

class Data {
	static function getTableName() {
		throw new Exception('WTF');
	}

	static function findRange() {
		$t = child::getTableName();
	}
}

class Prod {
	static function getTableName() {
		return 'PRODS';
	}	
}

Data::findRange(); // child = Data class
Prod::findRange(); // child = Prod class

if you require a class instance in order to use 'child' then
the whole point is moot - because you can already do

	$child = get_class($this);

inside the relevant function (assuming the function is not declared static,
and why would you declare it as such if your requiring an instance to use 'child'?).

maybe 'child' should be called 'callee' or even 'lsb' (that would make people
hit the docs for sure :-)). alternatively maybe 'this' could be used as the LSB keyword:

	this::foo();

the samentics for determining what class is referred to with 'this::' is akin to
that used for determining what class is referred with '$this->', no?

MAYBE php6 should do late static binding for 'self', akin to other OO oriented
scripting langs .. and just live with BC. I seriously wonder whether much code would
break ... given that 'self' is not currently late binding how often would people have actually
overwritten static methods ion child classes that are being called via the 'self' syntax
in [parent] classes?

---

## #30072 — Etienne Kneuss — 2007-06-05T15:57:51+00:00

URL: https://externals.io/message/29820#30072 · In reply to: #30071

Jochem Maas wrote:
> Bart de Boer wrote:
>   
> > […]
>
> ...
>
>   
> > […]
>
> huh??? the 'child' class would refer to the class that was actually named
> when then call to the method was made (thats what late static binding means,
> does it not?):
>
> class Data {
> 	static function getTableName() {
> 		throw new Exception('WTF');
> 	}
>
> 	static function findRange() {
> 		$t = child::getTableName();
> 	}
> }
>
> class Prod {
> 	static function getTableName() {
> 		return 'PRODS';
> 	}	
> }
>
> Data::findRange(); // child = Data class
> Prod::findRange(); // child = Prod class
>
> if you require a class instance in order to use 'child' then
> the whole point is moot - because you can already do
>
> 	$child = get_class($this);
>
> inside the relevant function (assuming the function is not declared static,
> and why would you declare it as such if your requiring an instance to use 'child'?).
>
> maybe 'child' should be called 'callee' or even 'lsb' (that would make people
> hit the docs for sure :-)). alternatively maybe 'this' could be used as the LSB keyword:
>
> 	this::foo();
>
> the samentics for determining what class is referred to with 'this::' is akin to
> that used for determining what class is referred with '$this->', no?
>
> MAYBE php6 should do late static binding for 'self', akin to other OO oriented
> scripting langs .. and just live with BC. I seriously wonder whether much code would
> break ... given that 'self' is not currently late binding how often would people have actually
> overwritten static methods ion child classes that are being called via the 'self' syntax
> in [parent] classes?
>   
Hello,

In an instance, fetching the class and running call_user_func is quite 
overkill, hopefully the dynamic access of class method/member/const will 
get accepted/commited. There is no reason (implementation wise) to 
restrict LSB to static callstacks only.

By the way, "child" is not a good term either as it won't always 
represent the child, i.e. the class itself.

Changing the behavior of "self" seems like a bad idea, it will make 
every script using "self" (many) rely on the call stack, which will 
among other things break BC and slow things down.


-- 
Etienne Kneuss
http://www.colder.ch
colder@php.net

Men never do evil so completely and cheerfully as 
when they do it from a religious conviction.
-- Pascal

---

## #30073 — Bart de Boer — 2007-06-05T16:28:39+00:00

URL: https://externals.io/message/29820#30073 · In reply to: #30071

> Bart de Boer wrote:
> > […]
>
> ...

> > […]
>
> huh??? the 'child' class would refer to the class that was actually named
> when then call to the method was made (thats what late static binding
> means,
> does it not?):
>
> class Data {
> 	static function getTableName() {
> 		throw new Exception('WTF');
> 	}
>
> 	static function findRange() {
> 		$t = child::getTableName();
> 	}
> }
>
> class Prod {
> 	static function getTableName() {
> 		return 'PRODS';
> 	}
> }
>
> Data::findRange(); // child = Data class
> Prod::findRange(); // child = Prod class
>

I think I misunderstood what was meant by late static binding. Thank you
for clearing that up. And my sincerest apologies to everyone to whom I
might have caused confusion.


> if you require a class instance in order to use 'child' then
> the whole point is moot - because you can already do
>
> 	$child = get_class($this);
>
> inside the relevant function (assuming the function is not declared
> static,
> and why would you declare it as such if your requiring an instance to use
> 'child'?).
>

I thought late static binding had something to do with accessing static
_variables_ in child classes. You're currently solving that problem by
defining a static function getTableName() in the child class. But I think
that isn't very efficient when you're dealing with complex objects and/or
arrays which would need to be accessed frequently.

If it were possible your code example could be solved as:

<?php

class Data {
	static function findRange() {
		if (!child::$tableName)
			throw new Exception('WTF');
		else
			return child::$tableName;
	}
}

class Prod {
	static $tableName = 'PRODS';
}

?>

But it seems this feature request belongs in a different thread. :)



> maybe 'child' should be called 'callee' or even 'lsb' (that would make
> people
> hit the docs for sure :-)). alternatively maybe 'this' could be used as
> the LSB keyword:
>
> 	this::foo();
>
> the samentics for determining what class is referred to with 'this::' is
> akin to
> that used for determining what class is referred with '$this->', no?
>
> MAYBE php6 should do late static binding for 'self', akin to other OO
> oriented
> scripting langs .. and just live with BC. I seriously wonder whether much
> code would
> break ... given that 'self' is not currently late binding how often would
> people have actually
> overwritten static methods ion child classes that are being called via the
> 'self' syntax
> in [parent] classes?
>

Now I understand why this:: might be confusing since it is meant for
objects. self:: would mean we can't access stuff in the current class
anymore. What about

derived::

or

extended::

?

---

## #30074 — Etienne Kneuss — 2007-06-05T17:17:18+00:00

URL: https://externals.io/message/29820#30074 · In reply to: #30073

Bart de Boer wrote:
> I thought late static binding had something to do with accessing static
> _variables_ in child classes. You're currently solving that problem by
> defining a static function getTableName() in the child class. But I think
> that isn't very efficient when you're dealing with complex objects and/or
> arrays which would need to be accessed frequently.
>
> If it were possible your code example could be solved as:
>
> <?php
>
> class Data {
> 	static function findRange() {
> 		if (!child::$tableName)
> 			throw new Exception('WTF');
> 		else
> 			return child::$tableName;
> 	}
> }
>
> class Prod {
> 	static $tableName = 'PRODS';
> }
>
> ?>
>
> But it seems this feature request belongs in a different thread. :)
>
>
>   
Late static binding can also be used to access static properties, of 
course. The same class resolution mechanism is used by foo::$member and 
foo::method(); so the keyword would apply to both.
Same with magic syntax like $a = new self();
>
> Now I understand why this:: might be confusing since it is meant for
> objects. self:: would mean we can't access stuff in the current class
> anymore. What about
>
> derived::
>
> or
>
> extended::
>
> ?
>   

It's always dangerous to introduce a new keyword, as it can/will break 
BC (i.e what if somebody has defined a function derived(), the parser 
would choke on that).

I'm personally fine with static, even if it may eventually introduce 
some confusion.

Regards

-- 
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as 
when they do it from a religious conviction.
-- Pascal

---

## #30076 — Bart de Boer — 2007-06-05T18:28:07+00:00

URL: https://externals.io/message/29820#30076 · In reply to: #30074

Etienne Kneuss wrote:
>
> It's always dangerous to introduce a new keyword, as it can/will break 
> BC (i.e what if somebody has defined a function derived(), the parser 
> would choke on that).
>
> I'm personally fine with static, even if it may eventually introduce 
> some confusion.
>
> Regards
>

Perhaps we should just introduce a new keyword? Isn't this one of those 
few cases where you should? Words like 'derived' and 'extended' are very 
unlikely function names anyway. More likely people would call them 
derive() or extend().

FWIW: "function derived()" gives me 0 results on Google code search. :)