The impoliteness of overriding methods

[Paulo Pinto]

On Thursday, 20 December 2012 at 08:35:34 UTC, foobar wrote:
> 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)

Me bad.

I just skimmed thru it yesterday, so I missed the main issue.

Sorry about that.