The impoliteness of overriding methods

[H. S. Teoh]

On Thu, Dec 20, 2012 at 08:26:18AM +0100, Jacob Carlborg wrote:
> On 2012-12-20 01:06, H. S. Teoh wrote:
> >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/
[...]
> >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
> >
> 
> What's the difference compared to calling "super".
[...]

The difference is that you can do things like this:

	class Base {
		abstract void chainMe() {
			if (condition) {
				chainMe();	// recursion
			} else {
				inner.chainMe();
			}
		}
	}

Which cannot be easily reproduced using .super.


T

-- 
Ruby is essentially Perl minus Wall.