[Python-3000] Abilities / Interfaces

[Guido van Rossum]

On 11/22/06, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> > 2. Do we need interfaces if we have generic functions?
> >
> > Phillip Eby argues that we don't need interfaces, because the right
> > API for generic functions makes it easy to do what we do with
> > interfaces. Let me paraphrase his argument.
>
> I agree that we don't *need* interfaces to have generic functions,
> just like we don't need them to have adaptation.  Using your
> example, consider Flatten as a base class, and F as an adapter
> registry containing adapters Fi from C to Flatten.  It's feasible.
>
> Interfaces provide greater value for both approaches.  A short
> usage case, shortened from the other thread.

Right.

> """
> Let's say that you create a library named libfruit, and that it
> implements a very nice IFruit interface.  This library is so nice
> and shiny that it becomes widely used, and thus many ways to handle
> a fruit are developed by third parties.  Now, someone else has a
> libapple library, which unfortunately is a bit outdated, and wasn't
> designed to work with the shiny libfruit library.
>
> With interfaces, all you need to do is define an adapter from Apple
> to IFruit, and instantly all the widely available frameworks will
> be handling apples just fine.
> """
>
> Without interfaces, we won't be able to say "in all places, use the
> generic method registered for an IFruit whenever an Apple is seen".

Well, this assumes automatic adaptation (which is off the table), *or*
everything that uses IFruits must always explicitly invoke some
adapter, rather than just assuming that it is passed an IFruit. Or it
only works for generic functions that are declared as taking IFruit --
there are many other situations where an IFruit could pop up without
directly being the argument of some (generic) function.

Consider container types, which haven't figured prominently in this
thread yet. Suppose I have a function that expects a sequence of
IFruits. Now I have a sequence of Apples. I don't think there's a
reasonable mechanism that lets me pass this to that function; I will
need to map it to a sequence of IFruits explicitly.

> Using generic functions, the same is true.  The only difference is
> that with generic functions each "adapter registry" is capable of
> adapting only to a single "interface", thus removing the need to
> explicitly declare it.

You've lost me here. A less abstract example might work better.

> > 3. API design -- how do we spell the various concepts? E.g.
> > has_ability(x, A) asks whether object x has the ability A;
> > provides_ability(C, A) asks whether class C provides the ability A to
> > its instances.
>
> I'm sure you're aware about it, but in Zope 3 terminology, these
> are 'provide' and 'implement', respectively.

I like provide, but I'm not so sure about implement, since it is
awfully ambiguous -- most of the time it is the class that does the
implementing. That's why I settled for "has".

> > - We need to come up with syntax for the common case, declaring a
> > class that claims to provide some abilities. Some thoughts: putting
> (...)
>
> Have you considered class decorators?
>
>   @implements(FooBar)
>   class Baz:
>      ...

No, I'm still waiting for someone to write a PEP for those. But as far
as ideas go it's a fine idea.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)