Now, let's say the "base" class is called "Entity". And let's say I have an inherited class called "Client":Abstract Class Entity { function read() {} function delete() {} ... } Class Client extends Entity { public $id; public $first_name; public $last_name; static public $structure = "<? structure of Client ?>"; } Now, imagine you are programming the "delete" function in class Entity. And you have to use the $structure variable.
If you mean Client's $structure, the you have to use static::$structure and it should work. However it's quite a bad design here since you have no way to ensure class inheriting from Entity would have $structure.
Since all the objects you are manipulating are "Client" objects (or other inherited "table objects"), it would be logical to write: parent::$structure
It won't be since Entity has no parent, so delete() in Entity definitely can't use this keyword.
Personally, I think one should give the programmer the choice, exactly like the programmer is given the choice between __CLASS__ (now, like it is written steadily in the code) and get_parent_class() (at run time, like objects are really instantiated).
__CLASS__ returns name of the class, get_parent_class() is the name of parent class, those are entirely different things, nothing to do with compiler/run time. Class always has one name and one parent or none.
I may be wrong, but I think LSB occurs every time you need to do something in a RELATIVE way (get_parent_class(), parent::), because there is an
What do you mean by "RELATIVE"?
ambiguity upon what you consider as your reference, when you write something like parent::$structure.
There's no any ambiguity - parent:: always means the name of the class you wrote after the keyword "extends".
-- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
