The impoliteness of overriding methods

[foobar]

On Thursday, 20 December 2012 at 19:46:25 UTC, H. S. Teoh wrote:
> On Thu, Dec 20, 2012 at 08:30:36PM +0100, foobar wrote:
>> On Thursday, 20 December 2012 at 14:51:31 UTC, Dan wrote:
> [...]
>> >I think it is more than syntactic sugar and in this case it is
>> >trivial because you as a designer of Base anticipate only one
>> >level of Derived. But, assume there are to be 2, 3, 4, or more
>> >levels of derivation. In fact, maybe you don't know how many
>> >levels there will be. For a chain of B->D1->D2->D3 I don't 
>> >see how
>> >you can up front get the same effect this way. At the level 
>> >of D2,
>> >base will skip the implementation of precious() in D1. At the
>> >level of D3, base will skip the implementation of precious() 
>> >in D1
>> >and D2, etc. Chaining is lost beyond the first level. It is 
>> >as if
>> >something is done in one direction, you want it done the 
>> >other and
>> >you provide an example that does the reversion as long as 
>> >there
>> >are only two entries. It is not truly a general solution.
>> >
>> 
>> You misunderstand. It is precisely what the quote bellow says 
>> - it
>> saves you from coming up with new names. The same pattern can 
>> be
>> applied multiple times for the multi-derivation case you bring 
>> up,
>> it's just needs more method names.
>> 
>> To extend my previous example:
>> 
>> class Derived {
>>   override precious() {
>>     beforeDerived();
>>     furtherPrecious();
>>     afterDerived();
>>   }
>> }
>> 
>> class FurtherDerived : Derived {
>>   void furtherPrecious() {...}
>> }
>> 
>> Now, we get this call chain:
>> base.myPrecious() -> Derived.precious() ->
>> FurtherDerived.furtherPrecious()
>> This can be extended ad infinitum.
> [...]
>
> But the fact that you keep having to invent new names is itself 
> the
> problem. It inevitably leads to horrible APIs that consist of 
> names
> suffixed by numbers: precious(), precious1(), precious2(), 
> precious3(),
> ad nauseaum. Method names that are suffixed by numbers are, as 
> a rule,
> an indication of bad API design. They also make your derived 
> classes
> immovable around the hierarchy, because to override their 
> parent's
> method, they have to use the exact name that's introduced by 
> the parent
> class, otherwise they risk accidentally short-circuiting part 
> of the
> chain.
>
> Whereas BETA's unification of the entire chain of calls under a 
> single
> name means that it's trivial to shuffle derived classes around 
> the
> hierarchy -- you're guaranteed they only overload their 
> immediate
> parent's method, and it stems the inevitable tide towards the 
> horrible
> number-suffixed method names.
>
> I'm not saying that the BETA approach cannot be represented by 
> the
> traditional approach -- they are functionally equivalent, as 
> you point
> out. It's just that for some use cases, the BETA approach is 
> superior.
> (All high-level languages compile to ASM, but that doesn't mean 
> they add
> no value to programming directly in ASM.)
>
>
> T

Yeah, I agree with all of the above points and in a completely 
new language designed from scratch I may very well prefer the 
more principled Beta approach over the "regular" D approach.

But, In our current circumstances and given that D indeed already 
implements a functionally equivalent feature which we are not 
going to remove or replace, I just don't see adding this, in 
essence a duplicate feature, worth the complexity cost. As Anderi 
phrases that - it just doesn't pull its weight.

It's all a matter of trade-offs and we cannot and should not 
strive to put all possible feature combinations and 
implementation variants into D.