On Monday 15 July 2002 09:33 pm, Guido van Rossum wrote: ... > I'm happy to allow for a way to state explicitly that Sub doesn't > implement IInterface, despite deriving from Super which does. But I > think it ought to inherit this property by default (this is in fact Yes, such a default would probably be handier than the opposite one in most cases. > what Zope does AFAIK). Otherwise creating minor variations on a class > would be quite a pain -- you'd have to repeat all the interfaces > implemented by the base class; and what if a later version of Super > implements more interfaces? This is actually a difficult point. If I have to explicitly state all the interfaces of Super that I want to _exclude_, and Super adds some more interfaces tomorrow, then it's quite possible that my class is suddenly broken -- it doesn't guarantee the invariants that says it guarantees, any more -- and I don't even know about it. At this point I'm thinking of my class as "a component", used by client code for its interfaces and contracts. Implementation inheritance is iffy enough in the component-world -- if it carries a baggage of exposing an a priori unknown set of interfaces it becomes basically unfeasible. > I would think that it's much more common > to extend a class while maintaining its contract than to inherit for > implementation only, even though there are important examples of the > latter. This is probably true. But maybe the explicitness we want is not per-interface: it's suddenly become an explicitness of "inheriting for implementation" vs "inheriting to extend" (with IS-A), just like C++'s private vs public inheritance (except, one hopes, done right -- i.e. with effect on visibility, not on accessibility). Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4