Home Original page

Implementing interfaces with inheritance, good or bad?

Andrae Muys amuys at shortech.com.au
Mon Feb 25 19:00:19 EST 2002 
Tripp Scott <tripps81 at yahoo.com> wrote in message news:<mailman.1014655721.10070.python-list at python.org>...
> I just saw:
> 
>   http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/68445
> 
> in which interfaces are implemented using class, and a class 
> implementing one or more interfaces subclasses the interfaces 
> class(es). Now suppose class C implements two Interfaces, I1 and 
> I2. Both interfaces define an operation foo(). In one case, I 
> want to instantiate C because of I1, and in other case, because 
> I need a class that implements I2. How does C implement both 
> foo() operations (since foo() will be implemented as a method)? 
> And how do I tell C that I want I1, or I2? With an argument to 
> __init__? Any other way?
> 
> I prefer providing Interface lookup via other mechanism, like 
> with the __implements__ class attribute as done in Zope's 
> Interface module. But are there any advantages of interfaces 
> being done with inheritance?
> 

Put simply, either the semantics of one of I1.foo() or I2.foo() are a
subset of the other, or your design is broken regardless of how you
implement interfaces.  If the above condition holds, then simply
implement the stricter semantic and you're fine.  If it dosn't hold
then you have to redesign/refactor/rethink your class/interface design
'cause it's borken :(.

The interface proposals I've seen for python do provide a way around
this, but these don't follow the common definition of 'interface' you
are thinking of.  Rather they propose to provide a standardised means
of requesting an interface-adaptor from a given class to a given
contract.

OTOH I'm far less interested in this then in seeing generator
comprehensions and the new xmethods.... built in support for
lazy-evaluated lists, I personally can't think of too many things
cooler! :)

Andrae
More information about the Python-list mailing list