This is a collection of responses to various things that don't appear to have been resolved yet:
Phillip writes: > if a target protocol has optional aspects, then lossy adaptation to it is > okay by definition. Conversely, if the aspect is *not* optional, then > lossy adaptation to it is not acceptable. I don't think there can really > be a middle ground; you have to decide whether the information is required > or not.
I disagree. To belabor Alex's example, suppose LotsOfInfo has first, middle, and last names; PersonName has first and last, and FullName has first, middle initial and last. FullName's __doc__ specifically states that if the middle name is not available or the individual does not have a middle name, then "None" is acceptable.
The error, IMO, is in registering an interface-to-interface adapter from PersonName to FullName; at best, it should be explicitly registered only for concrete classes that lack some way to provide a middle name.
If you don't want to lose data implicitly, don't register an implicit adaptation that loses data.
You're probably going to say "okay, then register a LotsOfInfo->FullName converter", and I agree. But if no such converter is registered, I would rather have a TypeError then an automatic conversion which produces incorrect results.
Then don't register a data-losing adapter for implicit adaptation for any possible input source; only the specific input sources that you need it for.
> it's difficult because intuitively an interface defines a *requirement*, so > it seems logical to inherit from an interface in order to add requirements!
Yes... I would fall into this trap as well until I'd been burned a few times.
It's burned me more than just a few times, and I *still* sometimes make it if I'm not paying attention. It's just too easy to make the mistake. So, I'm actually open to considering dropping interface inheritance.
For adapters, I think it's much harder to make this mistake because you have more time to think about whether your adapter is universal or not, and you can always err on the safe side. In truth, I believe I much more frequently implement class-to-interface adapters than interface-to-interface ones. I can always go back later and declare the adapter as interface-to-interface if I want, so there's no harm in starting them out as class-to-interface adapters.
Gee... I'm understanding the problem a little better, but elegant solutions are still escaping me.
My solution is to use class-to-interface adaptation for most adaptation, and interface-to-interface adaptation only when the adaptation can be considered "correct by definition". It seems to work for me.
_______________________________________________ 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
