[Python-3000] Adaptation: T->P vs P->P

[Tim Hochberg]

In this thread, Alex has been advocating adaption where types are 
adapted to protocols: T->P adaption for short. By contrast, my two 
sample implementations have involved Protocol->Protocol adaption where 
objects that implement a certain protocol are adapted to another 
protocol: P->P adaption for short. I suppose this also could be 
considered T->P->P adaptation since you look up the protocol from the 
type, but let's stick with the terminology P->P adaption.

Alex has been advocating for adaption for quite a while (I imagine it 
seems like forever to him), so I give his views here great weight. 
Still, something about T->P adaption has been bothering me, but until 
now I haven't been able to put my finger on it beyond a vague sense that 
pressing concrete types into service in this way is asking for trouble.

Here's the problem I have with T->P adaption: it increases coupling 
between the various clients of the adaption process. Lets talk about 
these clients, I believe Alex said there were four:

1. The author of the type: T
2. The writer of the adapter: A
3. The person defining the destination protocol: P
3. The user of the whole shebang: U

Now under a T->P regime, T needs to search out all relevant adapters and 
register them for their type. Similarly when adding a new adapter, A 
needs to search out all relevant classes and register the new adapter 
for them. Thus A and T become highly coupled.

On the surface, the P->P regime is not much different. In this case, 
when creating a new class, T needs to search out all relevant protocols 
and register their type with them. Similarly, A needs to search out all 
relevant source protocols and register the adapter.

[I realize that I've artificially constrained who registers what, but 
the fact remains that someone has to do the registrations at some point. 
Another issue that I'm glossing over is that in P->P adaption there is 
one more actor: the author of the source protocol. I don't think that 
this materially affects any of the conclusions.]

However, there is a huge difference in scale here. A class will 
typically only satisfy a few protocols, whereas it could potentially be 
associated with many adapters. Similarly an adapter will typically be 
associated with only a single source protocol, but it may be associated 
with many, many types. Just to make this concrete, I imagine there will 
be many adapters that work on every sequence type; doing all of those 
registrations could be quite a challenge regardless of which actor is 
charged with it.

As another way to get a sense of the coupling here, let's define A=>B to 
mean "A needs to know about B". For T->P adaption:
    T=>A or A=>T or P=>(A and T) or U=>(A and T and P)
For P->P adaption:
    T=>Psrc or P=>Psrc or U=>Psrc
  Generally A can be assumed to know about Psrc, so I've left that out.

Again, these look somewhat similar on the surface, but in practice it's 
much more feasible for one of the actors to know about the few protocols 
relevant to the case in question than it is for them to know about the 
potentially large number of types and adapters.

And that's why I'm uncomfortable with T->P adaption. I hope I've managed 
to present that with something resembling clarity.

Regards,

-tim