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 -- http://mail.python.org/mailman/listinfo/python-list