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();
}
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(); }
}
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.
--
Kind Regards
Benjamin Thaut
