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
- 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.
Repoze-dev mailing list