On Thu, Dec 20, 2012 at 12:11:34AM +0100, Andrej Mitrovic wrote: > Some interesting blog post: > http://journal.stuffwithstuff.com/2012/12/19/the-impoliteness-of-overriding-methods/ > > It's a post about a common problem in class design, I've ran into it a > few times in D too. [...]
Interesting concept. So "polite" overriding is simply a kind of override where the derived class method has a vtable entry separate from the base class method's entry (and thus needs explicit invocation from the base class), whereas the usual "impolite" overriding is a kind of override where the derived class method replaces the vtable entry of the base class method. I can see use cases for both kinds of overriding. Interestingly enough, in the "polite" overriding case, the call to inner is undefined until it's defined in the derived class. Which means that a method that calls inner is a kind of pseudo-abstract method (since abstract methods are those that *must* be implemented by the derived class). So if we were to implement this in D, we could extend the meaning of 'abstract': class Base { // The current, usual overridable method void replaceMe() { writeln("A"); } // Abstract, because chain(chainMe) is undefined until // the derived class implements it. abstract void chainMe() { writeln("B"); inner.chainMe(); // call derived class method // 'inner' is a tentative // keyword writeln("C"); } } class Derived : Base { override replaceMe() { writeln("D"); Base.replaceMe(); writeln("E"); } // Base.chainMe is abstract, so we have to implement // this method. override void chainMe() { writeln("F"); } } void main() { auto d = new Derived(); d.replaceMe(); // prints D A E d.chainMe(); // prints B F C } T -- Food and laptops don't mix.