On 4/27/09 1:18 PM, Chris McDonough wrote: >> I find the introduction lacking; why do I care about indirection, >> what's the benefit. > > Good point. > > Um. Why *do* we care about indirection? In particular, why do we care about > this sort of generic-function-ish dispatch pattern we call adaptation? Why do > we care about it for *every* application? I'm too brainwashed to answer that > question without thinking about views. If we want something to be bit off by > the larger Python community, we need an answer for this.
Answering myself with the kind of navel-gazing which is sure to drive Tres nuts ;-): - We use the heck out of indirections during unit testing. In most of the apps I write personally, the ZCA indirections are the only thing that make it *possible* to write unit tests rather than needing to write functional tests. But typically during testing the idea that some *adapter* is registered against more than one "requires" interface is just something that we deal with rather something that is actively desirable (because we always only have one implementation during unit testing); the actual multidispatch is to support the below case. - We use adaptation and utility indirections in applications to allow people to override implementations without needing to change the code. Most non-Zope people associate this desire to provide pluggability, correctly or incorrectly, with "CMS" systems. But there's something to this conclusion because indeed the ZCA indirections were originally meant to replace use of something like acquisition to find values in "content space". I suspect we are quite brainwashed here, or at least incapable of discounting this use case, because we tend to treat every application as something that might turn into a framework. - We use utility indirections (or at least I do) to retrieve application-specific configuration values (e.g. BFG's ISettings utility, which offers no behavior except as a bag-of-names). I have some ideas about how you might layer several systems together to allow people to only bite off one bit of software for each of these cases. #2 is the most problematic and would be at a higher layer. - C _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
