>> If addPreserveText() uses anything from Footer, it should not be called
>> from TextRun, but if it does not, it should be in Section.
> No, if it was in Section, all the child classes would have to override
> it and throw errors. That results in quite a bit of pointless
> boilerplate code to solve a problem that has just been created by this
> change (and really the original E_STRICT one). If the code path results
> in a call to addPreserveText in the other classes, it's a pretty serious
> error, and we need to catch that quick...
Not going to sound off on other subtopics in this thread, about which
my feelings are mixed, but your note here is pretty strange. I agree
with Stas and others that you are already using an antipattern, so if
a major justification is that you need to manually authorize a
subclass to call the super, you don't need to override and throw in
every possible subclass, how about something like this instead to
"whitelist":
interface preservable
{
public function addPreserveText();
}
abstract class section {
public function addPreserveText()
{
if (!isset(class_implements($this)["preservable"]))
throw new Exception("can't call super from disallowed
subclass");
echo "ready to rumble";
}
}
class footer extends section implements preservable {}
class header extends section {}
$myfoot = new footer();
$myfoot->addPreserveText(); // ready to rumble
$myhead = new header();
$myhead->addPreserveText(); // error
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
