[Python-3000] Implementations: A syntax for extending method dispatching beyond type/class inheritance
Gary Poster
gary at zope.com
Wed Dec 6 17:18:28 CET 2006
On Dec 6, 2006, at 4:20 AM, Jan Grant wrote:
> On Mon, 4 Dec 2006, Bill Janssen wrote:
>> Jim Jewett writes:
...
>>> (1) Interfaces can be placed on a separate (presumably light-
>>> weight)
>>> inheritance hierarchy.
...
>> And I don't really
>> see how it's lighter-weight -- can you explain that?
...
> Interfaces describe types: they are contracts.
Yes. I like Jan's (longer :-) reply.
Compared to ABCs, interfaces can also describe contracts that can be
fulfilled with any object--not just class instances, but classes
themselves, and functions.
Callables are an easy real-world example. If an interface describes
a callable object, the contract might be fulfilled by a function, a
class, or an interface. In Zope 3, we do that, often for factories,
where the implementation choice might depend on simplicty of
implementation, configuration options, and so on.
The ability to slam on an interface to an instance is another
important difference: specific instances can fulfill contracts that
all instances of the same class do not necessarily fulfill.
Other examples are perhaps more theoretical--with classmethods, a
class can fulfill a contract that we'd normally expect to be met with
an instance. I've used interfaces to describe a contract that a
class fulfills via classmethods, but I can't recall I really expected
the contract to be possibly fulfilled as an instance (though it
certainly could).
I'm not sure that Jan and I are actually addressing what Jim Jewett
intended to convey in his description of a "light-weight" interface
hierarchy. This is more a general flexibility of the interface
approach in comparison to ABCs. But the flexibility is very useful,
in my experience, and the concept of a "contract"--including the
politically correct notion that you shouldn't have preconceived
notions of who can fulfill the contract--describes (Zope 3)
interfaces well.
Gary
More information about the Python-3000
mailing list