The impoliteness of overriding methods

[sclytrack]

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.