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
--
If the comments and the code disagree, it's likely that *both* are wrong. --
Christopher
