>People generally prefer compile-time
>control which is derived from definition rather than per-instance
>runtime control (implementing interface vs. checking each time if class
>has certain methods).
It's me again, sorry.
So, if I understand you well, Stanislas, you are personally not much into
"static::" but more into making that sort of code working :
interface iC {
public $structure;
}
abstract class A implements iC {
public function display() {
echo self::$structure;
}
}
class B extends A {
static public $structure = "This is a string.";
}
$b = new B();
$b->display();
If so, what's the problem?
Is there a technical difficulty of implementation behind?
Or is it because we are unsure whether all the people asking for "LSB" would
be satisfied with that way?
BTW, here's a funny sort of polymorphism with static members that already
runs great with the actual PHP release:
interface iC {
function getStructure();
}
abstract class A implements iC {
public function display() {
echo $this->getStructure();
}
}
abstract class B extends A {
static public $structure = "This is a string from B.";
}
class C extends B {
static public $structure = "This is a string from C.";
public function getStructure() {
return self::$structure;
}
}
$c = new C();
$c->display();
Remove the definition of $structure in C, and the one in B will apply.
I suppose Michael Lively's example would be solved (the one with the
TableSelectQueries), if it could work the same way in a fully static context
(and without the help of an additional method like getStructure)
... Right ?
Baptiste
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
