Yet Another PEP: Interface Adapter Mechanism __adapt__

[Clark C. Evans]

On Sun, 25 Mar 2001, Alex Shindich wrote:
> Let's see... The abstract section of the PEP says: "This proposal allows 
> a standard and extensible method to ask two types of questions:  Is a
> particular object compliant with a given protocol?" The following
> describes the strategy pattern: "The Strategy pattern provides a means of
> parameterizing a component to accept an algorithm.  This keeps the
> component simpler, and lets clients pick and choose an algorithm
> specifically tailored to their needs." See any similarities?

The strategy pattern and the adapter pattern do use the concept of
abstraction, but this is as far as the similarity goes.

The strategy is used when there are two or more *algorithems* 
for accomplishing something, and rather than hard-code the 
technique used, this becomes a parameter.  The example used in 
the GOF text is line-breaking algorithems.

The adapter pattern is used to: "convert the interface of a 
class into another interface the clients expect".  See the
pluggable adapter example discussed a TreeDisplay, p142.  

Think of this proposal (and it isn't a PEP yet) as an
bi-directional adapter factory so that users of classes 
don't have to explore to find the appropriate adapter.
That's all, it is rather simple; however, it is a singleton
and standardization would help interoperability.  I'm 
putting it up as a sourceforge project and we will see who
uses it... if it is used and becomes popular, then it
can be submitted as a PEP.  I was too pre-mature and perhaps
out-of-line to suggest otherwise.

> 1. You are making an assumption that each class will provide adaptors to
> some set of protocols, thus entangling the class and available set of
> protocol conversions.

The technique ALLOWS a class to provide an adapter for objects
that it knows about, to convert the interface so that users
expecting the class's behavior will not be suprised.  Nothing
says a class must do this...

> Why can't protocol conversion live outside of the class?

It can.  It can live in an object, whatever.

> 2. Is adaption symmetric? If class A provides an adaptor for class B,
> mustn't class B provide an adaptor for class A?

Adaptation is often not symmetric.  

> 3. Versioning is not mentioned anywhere in your PEP. Once a class defines
> an adaptor for a protocol, the protocol better not change. Otherwise every
> adaptor needs to change to match the new definition of the
> protocol. 

This is not an interface proposal... it is not defining 
what a protocol means nor what it doesn't mean.  Any 
valid Python object can be a protocol.  The impl just
happens to have default behavior for Type and Class
protocols.

> That's all I have got so far... I'll send you more once 
> I read more

Thank you!

Clark