[Python-3000] Abilities / Interfaces

[Guido van Rossum]

On 11/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 09:42 AM 11/22/2006 -0700, Steven Bethard wrote:
> >Yeah, it certainly seems like in both this case and the string case,
> >there needs to be some shorthand for saying "implements all the basic
> >String/Number/whatever methods".
>
> But we are probably better off composing such a concept *from* the methods,
> rather than having the concept be merely a container *of* methods.
>
> This is basically the difference between Java interfaces and Haskell's
> notion of "typeclasses".  You can define typeclasses like "ordered" or
> "four-function arithmetic" and it's okay if they overlap, because they're
> defined in terms of the operations you can perform.  So nothing prevents
> somebody else from making "six-function arithmetic", or "reversible
> strings" or whatever.  And nobody has to *re*define their type as
> supporting these new "interfaces", as long as they have the requisite
> operations.
>
> So, if we have to have something like an interface, let's steal Haskell's
> version of the idea instead of Java's, because it involves a lot less
> typing.  :)

But the main thing that stands in the way of doing the right thing in
Java is that all interfaces have to be declared when the class is
defined. In *my* notion of abilities, this part being inspired by Zope
interfaces, you can state after the fact that a particular class
(which you didn't write) provides a given ability (which you didn't
write either). I think it would also be great if we had "ability
algebra" whereby you could state that a given ability A is composed of
existing abilities A1 and A2, and every object or class that already
has A1 and A2 will automatically be considered to have A.

However, I do *not* want to go the way of duck typing here -- if an
ability A claims that it is implemented by method foo(), and an object
x has a foo() method but doesn't explicitly claim to have ability A
(and neither does its class), then testing x for A should return
false. I think this deviates from Haskell, which seems to be big on
structural type equivalence (?).

So I think Python needs to do its own thing here, to some extent.

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