The impoliteness of overriding methods

[foobar]

On Thursday, 20 December 2012 at 20:58:40 UTC, Benjamin Thaut 
wrote:
> Am 20.12.2012 20:12, schrieb foobar:>
> > This argument is false.
> >
> > With the current "usual" design:
> > Base instance = new Derived();
> > instance.method(); // #1
> >
> > With Beta design:
> > Base instance = new Derived();
> > instance.method(); // #2
> >
> > In case #1, the call to method itself is virtual while the
> call to super
> > is not, whereas in case #2 the call to method is _not_
> virtual, but the
> > call to inner is virtual. Either way you get one virtual
> call. The
> > difference is the direction of the calls.
>
> No its not, if you have a chain that is longer than just 1 you 
> will have more virtual calls in the inner case.
>
> Kind Regards
> Benjamin Thaut

well, if the library developer wants to gain full control of that 
long call chain than yes, it will come with a certain price. The 
same price if you design the same way in C++. In practice however 
how common are those chains and how long are they? As far as I'm 
aware, inheritance of concrete classes has mostly fallen out of 
favor nowadays so practically speaking this is still 
insignificant.

Btw, This reminds me the OO class in university which makes it 
very clear that the C++/Java/C#/etc variant of inheritance is 
inherently flawed. It conflates two orthogonal concerns - 
sub-typing and sub-classing.
Small-talk for example is dynamically typed so inheritance only 
serves the sub-classing concern. Interfaces in Java where 
designed to serve only the sub-typing concern.

I find Rust's trait system fascinating precisely because they 
realized this and did not repeat the same old mistake. They 
haven't addressed fully the sub-classing relation yet but I'm 
eagerly awaiting any developments in that area.