[Python-3000] Abilities / Interfaces: why not adapt()?

[Jim Jewett]

On 11/21/06, Paul Moore <p.f.moore at gmail.com> wrote:
> I'd like to see some clear evaluation of the pros and cons of the 3 -
> interfaces, adaptation, and generic functions. My feeling is that they
> are to some extent "competing" proposals, and we need agreement (or
> BDFL ruling!) on which is the way forward, before we start discussing
> specifics.

Interfaces
==========

An interface is the equivalent of

    >>> obj.magic_name = magic_value

Many function decorators do no more than this.  Function (or method,
or class) annotations can be very useful.  They do rely on everyone
following the same convention, so they end up with most of the same
drawbacks as an isinstance check.  (If you implement them by
inheriting from a specified otherwise empty class, then they are
equivalent to isinstance.)


Adaptations
===========

An adaptation is the equivalent of

    >>> obj = MagicAdapter(obj)

Adaptation is strictly more powerful than interfaces.  It may be
simpler to understand/write/use if it already has interfaces to build
on.  Think of it as dynamic typecasting.

Instead of saying "Is this an X?", you say "I want this to be an X".
If the object is already an X, then you lose only the time spent to
verify that (similar to an assert).  If it isn't an X, then the
adapter can turn it into an X, or return a new (equivalent) object
that is an X.  __index__ is an example -- if you have an int or a
long, you get it back.  Otherwise, you get the equivalent int or long.



Generic Functions
=================

Generic functions are the most powerful, but they are also the hardest
to get your head around.  They make metaclasses seem straightforward.
They are less difficult if you have Adaptation and Interfaces around
to build on.  I cannot come up with a one-line equivalent.

    defop foo(arg1:Int, arg2:Seq): ...

This changes what foo(1, []) will do, but not what foo(1.0, 7) would do.

-jJ