On Thursday, 20 December 2012 at 09:07:35 UTC, Benjamin Thaut
wrote:
This polite overriding is a nice idiom. But it does not solve
the most frequent problem I have at work (in C++)
Assume you have a customer facing class they derive from to
implement own features.
abstract class Base
{
abstract void doStuff();
}
I guess in the polite version you would make the call to the
derived version here. The derived version wouldn't have to call
super or anything.
The customer now derives from this class and implements
doStuff. Because it is abstract he does not call the base
implementation.
Now you have to do some changes and suddenly the doStuff method
is no longer abstract and does something important that should
always be executed.
abstract class Base
{
void doStuff(){ prepareSomething(); }
}
The best you can do is put a line into the changelog "make sure
to call the base implementation of Base.doStuff...". Which the
customer most likely won't read and thus usually will fill a
issue report with the Support deparment, because the code
breaks.
If there would be some kind of attribute supported by the
compiler, such as that the compiler ensures that the base
implementation is always called if the function is annotated
with this attribute the customer would automatically be
reminded by the compiler, and this would not be an issue.
It could look something like this:
abstract class Base
{
@mustcall void doStuff(){ prepareSomething(); }
}
@mustcallbefore @mustcallafter
Would these be automatically called in all derived versions?
@autocallbefore @autocallafter
Making a helper method that is called instead of doStuff is
usually not an option, because the customer might have calls to
doStuff in his code, which would still lead to a wrong
execution path.
