The impoliteness of overriding methods

[H. S. Teoh]

On Thu, Dec 20, 2012 at 09:49:40PM +0100, foobar wrote:
> On Thursday, 20 December 2012 at 19:46:25 UTC, H. S. Teoh wrote:
[...]
> >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.)
[...]
> 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.

Agreed, I don't think we should be adding new stuff to D that can
already be handled by existing mechanisms. D is already too complex for
its own good -- too many features whose mutual interactions with other
features aren't fully explored yet, which may turn out to have nasty
side-effects. We don't need to be making this problem worse.


T

-- 
Why ask rhetorical questions? -- JC