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

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to