At 07:04 PM 1/12/05 +0100, Alex Martelli wrote:
On 2005 Jan 12, at 18:58, Phillip J. Eby wrote: ...I have some data about people coming in from LDAP and the like, which I want to record in that SQL DB -- the incoming data is held in types that implement IPerson, so I write an adapter IPerson -> IFullname for the purpose.
This doesn't answer my question. Obviously it makes sense to adapt in this fashion, but not IMPLICITLY and AUTOMATICALLY. That's the distinction I'm trying to make. I have no issue with writing an adapter like 'PersonAsFullName' for this use case; I just don't think you should *register* it for automatic use any time you pass a Person to something that takes a FullName.
I'm adapting incoming data that can be of any of a huge variety of concrete types with different interfaces. *** I DO NOT WANT TO TYPECHECK THE INCOMING DATA *** to know what adapter or converter to apply -- *** THAT'S THE WHOLE POINT *** of PEP 246. I can't believe we're misunderstanding each other about this -- there MUST be miscommunication going on!
Indeed!
Let me try and be more specific about my assumptions. What *I* would do in your described scenario is *not* register a general-purpose IPerson -> IFullName adapter, because in the general case this is a lossy adaptation.
However, for some *concrete* types an adaptation to IFullName must necessarily have a NULL middle name; therefore, I would define a *concrete adaptation* from those types to IFullName, *not* an adaptation from IPerson -> IFullName. This still allows for transitive adapter composition from IFullName on to other interfaces, if need be.
IOW, the standard for "purity" in adapting from a concrete type to an interface can be much lower than for adapting from interface to interface. An interface-to-interface adapter is promising that it can adapt any possible implementation of the first interface to the second interface, and that it's always suitable for doing so. IMO, if you're not willing to make that commitment, you shouldn't define an interface-to-interface adapter.
Hm. Maybe we actually *agree*, and are effectively only arguing terminology? That would be funny, yet sad. :)
So, I'm not sure why you appear to argue for conversion against adaptation, or explicit typechecking against the avoidance thereof which is such a big part of adapt's role in life.
Okay, I see where we are not communicating; where I've been saying "conversion", you are taking this to mean, "don't write an adapter", but what I mean is "don't *register* the adapter for implicit adaptation; explicitly use it in the place where you need it.
"Adaptation is not conversion" is how I THOUGHT we had agreed to rephrase my unfortunate "adaptation is not casting" -- so if you're using conversion to mean adaptation, I'm nonplussed.
Sorry; I think of "noisy adaptation" as being "conversion" -- i.e. I have one mental bucket for all conversion/adaptation scenarios that aren't "pure as-a" relationships.
Needing to be explicit and therefore to typechecking/typeswitching to pick which adapter to apply is just what I don't *WANT* to do, what I don't want *ANYBODY* to have to do EVER, and the very reason I'm spending time and energy on PEP 246. So, how would you propose I know which adapter I need, without spreading typechecks all over my bedraggled *CODE*?!?!
See above. I thought this was obvious; sorry for the confusion.
I think we may be getting close to a breakthrough, though; so let's hang in there a bit longer.
_______________________________________________ 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
