> I've been thinking about this for a bit and even if you are right
> about being nice to have a way to call a function always after
> constructor. It could happen. You could have a DB class and in
> constructor the user/pass/host/options and then a separate method for
> init().
But that's not Call Super. Call Super specifically refers to always
calling an overridden method of the same name (and usually same
signature in languages supporting overloading) in a base class
(usually the closest parent).
Let's not mix up concepts: the relationship between methods of the
same name in the a class hierarchy has specific semantic baggage, if
not a single agreed-upon meaning, thus how some people say
"you should always be able to call super"
while others say
"you should never just assume you can call super *and* should never
author an API that requires it"
and still others say
"you can't assume, but the requirement happens, and when it is
required the language should be able to enforce the
requirement."
> But more often than not, I want to be able to dictate what the
> program is doing when I'm using libraries and so on that I'm
> extending, not the libraries do stuff on their own.
The question regarding Call Super isn't about libraries doing "stuff
on their own" vs. "stuff you dictate."
It's about "doing stuff on their own" vs. "dictating that you remember
to do stuff for bug-free operation, being unable to do that stuff on
their own."
Languages that have Call Super as a flexible, baked-in language
feature are able to contractually ensure Call Super _if a superclass
author chooses to use the pattern_. Doesn't mean you have to use it,
but it means you don't have to cross your fingers if you do use it.
(In the case of C++, you're always using the pattern if you have a
base ctor.)
Languages that don't support Call Super still have to support code
using the pattern in the real world, because not every user will use
the alternative Template Method due to seeming complexity (even if TM
is less prone to error). But those languages won't offer any way of
catching omissions in a subclass.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
