The impoliteness of overriding methods

[Benjamin Thaut]

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