late static binding

18 years ago by Ken Stanley — view source

unread

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"

18 years ago by Mike Lively — view source

unread

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

18 years ago by Ken Stanley — view source

unread

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"

18 years ago by Bart de Boer — view source

unread

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:

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.

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Richard Lynch — view source

unread

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?

18 years ago by Jochem Maas — view source

unread

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.

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"

18 years ago by Bart de Boer — view source

unread

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:

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.

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"

18 years ago by Bart de Boer — view source

unread

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:

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.

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"

18 years ago by Richard Lynch — view source

unread

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.

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?

18 years ago by Bart de Boer — view source

unread

Richard Lynch wrote:

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.

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

18 years ago by Ken Stanley — view source

unread

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"

18 years ago by Bart de Boer — view source

unread

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

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.

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

18 years ago by Ken Stanley — view source

unread

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"

18 years ago by Jochem Maas — view source

unread

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?

18 years ago by Etienne Kneuss — view source

unread

Jochem Maas wrote:

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?

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

18 years ago by Bart de Boer — view source

unread

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

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

extended::

18 years ago by Etienne Kneuss — view source

unread

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

18 years ago by Bart de Boer — view source

unread

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

late static binding

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.

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.