[Python-Dev] PEP 246, redux
Phillip J. Eby
pje at telecommunity.com
Wed Jan 12 20:06:51 CET 2005
At 10:16 AM 1/12/05 -0800, Guido van Rossum wrote:
>For example, inteface B (or perhaps this should be a property of the
>adapter for B->C?) might be marked so as to allow or disallow its
>consideration when looking for multi-step adaptations. We could even
>make the default "don't consider", so only people who have to deal
>with the multiple A's and/or multiple C's all adaptable via the same B
>could save themselves some typing by turning it on.
Another possibility; I've realized from Alex's last mail that there's a
piece of my reasoning that I haven't been including, and now I can actually
explain it clearly (I hope). In my view, there are at least two kinds of
adapters, with different fidelity requirements/difficulty:
class -> interface ("lo-fi" is okay)
interface -> interface (It better be perfect!)
If you cannot guarantee that your interface-to-interface adapter is the
absolute best way to adapt *any* implementation of the source interface,
you should *not* treat it as an interface-to-interface adapter, but rather
as a class-to-interface adapter for the specific classes that need
it. And, if transitivity exists, it is now restricted to a sensible subset
of the possible paths.
I believe that this difference is why I don't run into Alex's problems in
practice; when I encounter a use case like his, I may write the same
adapter, but I'll usually register it as an adapter from
class-to-interface, if I need to register it for implicit adaptation at all.
Also note that the fact that it's harder to write a solid
interface-to-interface adapter naturally leads to my experience that
transitivity problems occur more often via interface inheritance. This is
because interface inheritance as implemented by both Zope and PyProtocols
is equivalent to defining an interface-to-interface adapter, but with no
implementation! Obviously, if it is already hard to write a good
interface-to-interface adapter, then it must be even harder when you have
to do it with no actual code! :)
I think maybe this gets us a little bit closer to having a unified (or at
least unifiable) view on the problem area. If Alex agrees that
class-to-interface adaptation is an acceptable solution for limiting the
transitivity of noisy adaptation while still allowing some degree of
implicitness, then maybe we have a winner.
(Btw, the fact that Zope and Twisted's interface systems initially
implemented *only* interface-to-interface adaptation may have also led to
their conceptualizing transitivity as unsafe, since they didn't have the
option of using class-to-interface adapters as a way to deal with more
narrowly-applicable adaptations.)
More information about the Python-Dev
mailing list