At 04:39 PM 1/14/05 +0000, Armin Rigo wrote: >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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4