On 2005 Jan 13, at 15:34, Clark C. Evans wrote: ...
The 'implicit' adaptation refers to the automagical construction of composite adapters assuming that a 'transitive' property holds. I've seen nothing in this thread to explain why this is so valueable, why
Let me play devil's advocate: I _have_ seen explanations of why transitive adaptation can be convenient -- the most direct one being an example by Guido which came in two parts, the second one a clarification which came in response to my request about the first one. To summarize it: say we have N concrete classes A1, A2, ... AN which all implement interface I.
Now we want to integrate into the system function f1, which requires an argument with interface J1, i.e.
def f1(x):
x = adapt(x, J1)
...
or in Guido's new notation equivalently
def f1(x: J1):
...
and also f2, ..., fM, requiring an argument with interface J2, ..., JM respectively.
Without transitivity, we need to code and register M*N adapters. WITH transitivity, we only need M: I->J1, I->J2, ..., I->JM.
The convenience of this is undeniable; and (all other things being equal) convenience raises productivity and thus is valuable.
James Knight gave a real-life example, although, since no combinatorial explosion was involved, the extra convenience that he missed in transitivity was minor compared to the potential for it when the N*M issue should arise.
it shouldn't be explicit,
On this point I'm partly with you: I do not see any real loss of convenience in requiring that an adapter which is so perfect and lossless as to be usable in transitivity chains be explicitly so registered/defined/marker. E.g., provide a
registerAdapter_TRANSITIVITY_SUITABLE(X, Y)
entry in addition to the standard registerAdapter which does not supply transitivity (or equivalently an optional suitable_for_transitivity argument to registerAdapter defaulting to False, etc, etc).
In terms of "should" as opposed to convenience, though, the argument is that interface to interface adapters SHOULD always, inherently be suitable for transitive chains because there is NO reason, EVER, under ANY circumstances, to have such adapters be less than perfect, lossless, noiseless, etc, etc. I am not entirely convinced of this but "devil's advocacy wise" I could probably argue for it: for the hapless programmers' own good, they should be forced to think very VERY carefully of what they're doing, etc, etc. Yeah, I know, I don't sound convincing because I'm not all that convinced myself;-).
and on the contrary, most of the "problems with adapt()" seem to stem from this aggressive extension of what was proposed: Automatic construction of adapter chains is _not_ part
Fair enough, except that it's not just chains of explicitly registered adapters: interface inheritance has just the same issues, indeed, in PJE's experience, MORE so, because no code is interposed -- if by inheriting an interface you're asserting 100% no-problem substitutability, the resulting "transitivity" may thus well give problems (PJE and I even came close to agreeing that MS COM's QueryInterface idea that interface inheritance does NOT implicitly and undeniably assert substitutability is very practical, nice, and usable...).
of the original PEP 246 and I hope it remains that way. I've outlined in several posts how this case could be made easy for a application developer to do:
- transitive adapters should always be explicit
What about "registered explicitly as being suitable for transitivity", would that suffice?
- it should be an error to have more than one adapter
from A to Z in the registry
OK, I think. There has to be a way to replace an adapter with another, I think, but it might be fair to require that this be done in two steps:
unregister the old adapter, THEN immediately
register the new one
so that trying to register an adapter for some A->Z pair which already has one is an error. Replacing adapters feels like a rare enough operation that the tiny inconvenience should not be a problem, it appears to me.
- when adaptation fails, an informative error message can
tell the application developer of possible "chains"
which could work
Nice, if not too much work.
- registration of transitive adapters can be simple command
application developers use: adapt.transitive(from=A,to=Z,via=M)
error message can tell an application developer
OK, convenient if feasible.
Considering all of your proposals, I'm wondering: would you be willing to author the next needed draft of the PEP in the minimal spirit I was proposing? Since I wrote the last round, you might do a better job of editing the next, and if more rounds are needed we could keep alternating (perhaps using private mail to exchange partially edited drafts, too)...
The 'registry' idea (which was not explored in the PEP) emerges from the need, albeit limited, for the application developer who is plugging a component into a framework, to have some say in the process. I think that any actions taken by the user, by registering an adapter, should be explicit.
Jim Fulton is VERY keen to have registration of adapters happen "behind the scenes" at startup, starting from some kind of declarative form (a configuration textfile or the like), given the deployment needs of Zope3 -- that shouldn't be a problem, it seems to me (if we have a way to to explicit registrations, zope3 can have a startup component that finds configuration files and does the registration calls based on that 'declarative' form).
This potentially opens the door to N-players scenarios for N>3, but, like going from 3-tier to N-tier applications, that's not as huge a jump as that from N==2 to N==3;-).
| BUT, and again, Philip has made this point, I can't reason about
| interfaces in the context of PEP 246, because interfaces aren't
| defined there. So PEP 246 can't make a clear statement about
| transitivity, precisely because it doesn't define interfaces. But does
| this harm PEP 246? I'm not sure.
Well, PEP 246 should be edited, IMHO, to assert that all 'implicit' adaptions are out-of-scope, and if they are supported should be done so under the direct control of the application developer.
So, are you willing to do that round of editing to PEP 246...? I'll then to the NEXT one which will still undoubtedly be needed...
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
