On 2005 Jan 12, at 20:06, Phillip J. Eby wrote:
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.
Even though Guido claimed I have been belaboring the following point, I do think it's crucial and I still haven't seen you answer it. If *any* I1->I2 adapter, by the very fact of its existence, asserts it's the *absolute best way* to adapt ANY implementation of I1 into I2; then why should the existence of two equal-length shortest paths A->I1->I2 and A->I3->I2 be considered a problem in any sense? Pick either, at random or by whatever rule: you trust that they're BOTH the absolute best, so they must be absolutely identical anyway.
If you agree that this is the only sensible behavior, and PyProtocols' current behavior (TypeError for two paths of equal length save in a few special cases), then I guess can accept your stance that providing adaptation between interfaces implies the strongest possible degree of commitment to perfection, and that this new conception of *absolute best way* entirely and totally replaces previous weaker and more sensible descriptions, such as for example in <http://peak.telecommunity.com/protocol_ref/proto-implication.html> that shorter chains "are less likely to be a ``lossy'' conversion". ``less likely'' and ``absolute best way'' just can't coexist. Two "absolute best ways" to do the same thing are exactly equally likely to be ``lossy'': that likelihood is ZERO, if "absolute" means anything.
((Preferring shorter chains as a heuristic for faster ones may be very reasonable approach if performance is a secondary consideration, as I've already mentioned; if performance were more important than that, then other ``costs'' besides the extreme NO_ADAPTER_NEEDED [[0 cost]] and DOES_NOT_SUPPORT [[infinite cost]] should be accepted, and the minimal-cost path ensured -- I do not think any such complication is warranted)).
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.
If you agree that it cannot be an error to have two separate paths of "absolute best ways" (thus equally perfect) of equal length, then I can accept your stance that one must ensure the "absolute best way" each time one codes and registers an I -> I adapter (and each time one interface inherits another interface, apparently); I can then do half the rewrite of the PEP 246 draft (the changes already mentioned and roughly agreed) and turn it over to you as new first author to complete with the transitivity details &c.
If there is any doubt whatsoever marring that perfection, that "absolute best way", then I fear we're back at square one.
Alex
_______________________________________________ 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
