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.
