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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com