Yet Another PEP: Interface Adapter Mechanism __adapt__

[Alex Martelli]

"Alex Shindich" <alex at server01.shindich.com> wrote in message
news:mailman.985588473.13759.python-list at python.org...
    [snip]
> 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?

Some vague ones, maybe.  Protocols need not be algorithms, nor
do components need to 'accept' protocols (it can well be the
other way round, for example).


> > > Another way of looking at your PEP is to say that you are
> > > asking for Python Java-like interfaces.
> >
> > No, actually there are other PEPs that do that.
> >
> That is true, there is PEP-245. But in some sense, an ability to determine
> "is-a" relationship is no different from asking "do you support
> protocol Blah?"

Clark's PEP Without A Number most often ends up asking a more
general question than 'are-you'/'do-you-support', namely:
    "Are you now, *or do you know how to wrap yourself to
        provide*, a supporter of protocol X"?
(when this is asked of the object); or:
    "Does object Y support you, *or do you know how to wrap
     it to obtain such a supporter*"?
(when this is asked of the protocol).

The duality is important, because protocols can be developed
after objects are, OR vice-versa, and this PEP lets either
case be supported 'non-invasively' wrt the pre-existing
component[s].

The question[s] don't receive a simple yes/no answer, which
would be of little use by itself; rather, in the 'yes' case,
the return is the required object-supporting-protocol-X, be
that the input object Y or some wrapper around it (this can
be ignored, and used as a simple boolean yes/no, in the rare
cases where the client only DOES care about a yes/no check,
of course; commonly, it will be saved and used for calls to
the relevant protocol methods).


> Other comments:
> 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. Why can't protocol conversion live outside of the
> class?

If I have a pre-existing protocol, say "FileObject", and I design
a new class which I intend to support this pre-existing protocol,
then the most natural residence for the code providing that support,
and the knowledge that the support is provided, seems to be in
the new class itself.

If I have a pre-existing type of objects, say builtin file-objects,
and I design a new protocol that is meant to encompass (maybe with
wrapping) said pre-existing objects, then the natural residence
seems to be in the protocol.

The case for residence in a third place yet seems more remote (both
objects and protocols pre-exist, I just want to add an adaptation)
and might be left as a future enhancement IMHO.


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

***NO***!!!  That would be absurd even if all classes were protocols.

E.g., a ReadableAndWriteableFileObject can surely be adapted (trivially,
by not wrapping) to satisfy a protocol ReadableFileObject, but that
in no way implies adaptation makes any sense the other way 'round --
read-only files may perfectly well exist (even physically, on a RO
media), why deny the fact in quest of nonexistent adaptation symmetry?

Further, *MANDATING* mutual (circular) dependency is about as far
from best software development practices as one can get.  If A
depends on (needs to know about) B, it's BY FAR better if we can
avoid any dependency of B on A.  Please read all that R. Martin
has to say on his www.objectmentor.com site (publications page)
then move on to Lakos' book (it's written for C++, but it's really
about dependency management as THE key issue with large scale SW).


> 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.

Looking at protocols as contracts between suppliers and consumers,
they had better never change unless ALL existing suppliers AND
consumers can be refactored appropriately -- whether one provides
a formally recognized idiom to adapt a few more suppliers to the
protocol, or not.


Alex