Alex Martelli wrote: > Kay Schluehr <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
