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
