Ideally, both the caller and the callee know (and write down) that the function's argument is a "reference to some kind of file stuff", a very general concept; then they can independently specify which concrete object they expect and provide, e.g. "a string naming a file", "a file-like object", "a string containing the data".
Yes, exactly! That's what I mean by "one use case, one interface". But as you say, that's because we don't currently have a way to separate these ideas.
So, in developing with PyProtocols, I create a new interface for each concept, possibly allowing adapters for some other interface to supply default implementations for that concept. But, for things like strings and such, I define direct adapters to the new concept, so that they override any "generic" adapters as you call them.
So, I have a path that looks like:
concreteType -> functionalInterface -> conceptInterface
Except that there's also a shorter concreteType -> conceptInterface path for various types like string, thus providing context-sensitivity. (Interestingly, strings are the *most* common instance of this situation, as they're one of the most "open to interpretation" objects you can have!)
> It also works for the module to define a target interface and register an > adapter to that, and introduces less complexity into the adaptation system.
Makes sense, but my fear is that people will soon register generic adapters all around... debugging nightmares!
Well, if you have "interface per concept", you *have* a context; the context is the concept itself.
_______________________________________________ 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
