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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
