Encouraging call super is still not the right way to go about this. As
I said before, even with the changes proposed, there's no way to
*contractually enforce* the call super pattern in this language.
That's why it is and will remain an antipattern. So all you're doing
is allowing people to more easily use the antipattern, instead of (a)
baking auto-super (contractual call super) into the language or (b)
pushing people to use a preferred pattern (Template Method or other).
Template Method in userland is not difficult (lightly tested):
trait templateInitializer {
private $inited;
final public function __construct( $arg1, $arg2 ) {
print "__construct in super calling inits...<BR>";
$this->init( $arg1, $arg2 );
$this->inited or self::init( $arg1, $arg2 );
}
protected function init ( $arg1, $arg2 ) { print "init in
super...<BR>"; $this->inited = true; }
}
class superClass3 {
use templateInitializer;
}
class subClass3a extends superClass3 {
protected function init ( $arg1, $arg2 ) { print "init in
sub...<BR>"; }
}
class subClass3b extends superClass3 {}
class subSubClass3a1 extends subClass3a {
protected function init ( $arg1, $arg2 ) { print "init in
sub-sub...<BR>"; }
}
new superClass3 ( null, null ); // runs root init
new subClass3a ( null, null ); // runs child init, then root
new subClass3b ( null, null ); // runs root init
new subSubClass3a1 (null, null); // runs grandchild, then root
You can extend this model to preInit() and postInit() methods, giving
even more flexibility. And in none of these cases does the subclass
need to "remember" to do anything.
This thread arose in response to what is undeniably a bad API
authoring practice (first allowing full ctor override and later
breaking BC without fanfare). Why are we letting the authors of
Richard's library off the hook and putting it on ourselves to develop
hacks? They obviously screwed up. What next? Do we let API consumers
override a `final` that they don't like? Just use the right pattern in
the first place. IMO.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
