Unintended inheritance

[Kay Schluehr]

Alex Martelli wrote:
> Kay Schluehr <kay.schluehr at gmx.net> wrote:
>    ...
> > To prevent unintended inheritance C# introduced a relatively complex
> > contract semantics using three modifiers virtual, override and new. Is
> > this issue serious for Python programmers, in particular for those
> > working in larger projects ( Twisted, Zope ... ) or is it not? If not,
> > why not?
>
> I have not found it to be a particular problem (in C++ as well as in
> Python or Java), because subclasses' coupling to superclasses is too
> strong anyway to expect everything to just work smoothly when the
> superclass's interface is changed, and even the most semidecent of
> unittests easily catch this specific problem -- obviously all subclasses
> must be recompiled and tested when a superclass's interface is changed
> in any way. Other kinds of coupling are subtler and more problematic
> (not so much in Python as in C++, I'd say, but it's arguable).
>
> Lakos' book on large-scale design for C++ has good advice on dependency
> control, which boils down to (WAY oversimplifying): each component must
> expose to all others only unchanging abstract interfaces; anything
> depending on anything beyond an abstract interface (as a subclass must)
> must be in the same component as what it depends on.  Inheritance, while
> way handy, introduces too-strong coupling (==dependencies) to be freely
> used across independently developed and maintained components; and any
> change in interface (I would argue, in fact, most any change in
> PROTOCOL, which is a stronger constraint) must occur on new, separate
> interfaces (which may well extend the existing ones, of course).
>
> Yes, frameworks (separately developed, large components which are
> *supposed* to be used via inheritance by separately developed and
> maintained components) are quite problematic in terms of Lakos' rules
> and guidelines (if you're at all interested in these subjects you should
> surely read Lakos' book, anyway: no summary can do it justice). But I
> believe (with no real-world experience of C#, admittedly) that they will
> remain essentially just as problematic with C#'s complex rules -- a new
> release of a framework, which changes protocols, will still be able to
> break uncountable independently developed and maintained smaller
> components, and the fact that the compiler catches the breakage (if, of
> course, the other components DO get recompiled) rather than relying on
> semidecent unittests is scant consolation -- there's still no bound to
> the amount of work that may be needed to repair the wreckage.
>
>
> Alex

Interesting statement, Alex, as always. I've found an interview with
Anders Hejlsberg from 2003 on Artima where he defended his C# design
decisions with regard to the problem of "unintended inheritance":

http://www.artima.com/intv/nonvirtual.html

A strange twist is Anders exemplification of "pragmatism" with which
Bruce Eckel seems to agree emphatically. I would indeed assume the
exact opposite: laisser faire by pragmatists and expressive control by
academics. I'm also not sure what I should think about the confusing
use of the word "versioning" that is placed concretely by Bruce Eckel (
"DLL hell" ) but more metaphorically by Anders. His remarks about the
difference of ingoing and outgoing interfaces are interesting but
remain a little underdeveloped. 

Kay