Tim Hochberg writes: > 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 > [...] P->P adaption for short.
> 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 I may be misinterpreting what Tim is saying here, but it sounds like this touches on the idea of *transitivity* in adaptation. That is, Tim is proposing that there are a small number of "protocols", but I can't tell the difference between a protocol and an adaption target so I am taking them to be synonomous. I am (and have been for nearly 2 years... Alex: your previous efforts at evangalism have not been *totally* useless) a fan of adaption. But I am *deeply* concerned about introducing transitive adaption where it is assumed that registering ((A B) f) and ((B C) g) implies ((A C) lambda x: f(g(x)) I have heard it argued previously (I apologize, but I forget who said this) that if f *really* adapts A to B and g *really* adapts B to C, then their composition must really adapt A to C, and I understand the mathematical inevitability behind this statement. But I fear that in the real world there are often subtle distinctions and corner cases that are ignored for the sake of practicality which make such transitive adaption dangerous. After all, a substantial portion of Python classes fail true to achieve true Liskov substitutability despite this being a widely-understood concept. Okay... time for me to stop attacking a position (pro transitivity) that no one has explicitly taken in this discussion and return to what Tim was saying. He claims: > 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. Tim's proposal (if I understand it correctly) depends on transitivity -- his idea is to have the class authors register as satisfying a small number of widely-known protocols (Psrc in his case), then use transitivity to infer ways to satisfy less well-known protocols. This is a tempting game... it avoids having to have even a third party know about both the type and the protocol to be satisfied. But I would rather FORCE someone (even a third party) to at least glance at the specific case and reassure us that it works. If the individual wants to do a quick and sloppy job rather than a careful one, then it is reduced to a question of whose libraries I trust, which I a problem I understand how to handle. To return to the example that we used previously in this thread, it seems that creating an __index__ special method would not be necessary if adaption were in place... we could instead ask classes to register an adapter to the "python.as_index" protocol. But if we were to infer that anything satisfying "python.as_int" necessarily satisfied "python.as_index", then we would have defeated the purpose of the feature. One last point: it is entirely possible that I have misunderstood completely. If so, please gently explain why. -- Michael Chermside _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
