The impoliteness of overriding methods

[foobar]

On Thursday, 20 December 2012 at 08:12:54 UTC, Paulo Pinto wrote:
> On Thursday, 20 December 2012 at 07:48:12 UTC, foobar wrote:
>> On Thursday, 20 December 2012 at 00:07:49 UTC, 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/
>>>> 
>>>> 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
>>
>> This is trivially implemented with a simple OO design pattern 
>> in any usual OO language:
>>
>> class Base {
>>  public override precious() {...}
>>  private void myPrecious() {
>>    before();
>>    precious();
>>    after();
>>  }
>> }
>>
>> class Derived {
>>  override precious() {...}
>> }
>>
>> Having syntax sugar is redundant given how simple this pattern 
>> is.
>
> No because in your example you have to write Base already for 
> that specific use case, whereas in BETA is up to the derived 
> class to do as it please.

Have you read the article?
The Beta design (btw, it's the same in smalltalk - the article is 
wrong on that point) is to give control to the base class. The 
base class in beta is written specifically for that use case and 
the derived has no-control. That's the entire point of this 
design. It is basically a restriction to allow only overriding 
abstract methods (with a slightly more convenient syntax)