Jim Fulton wrote:
Martijn Faassen wrote:
I appreciated you making it explicit, Shane, even though I already
knew and fully agree. :)
I sometimes express this principle as "magic is bad unless it's
perfect magic". Do post it on your blog.
Yes, it is a good thing to know, except that it is incomplete and
obscures an important point. Magic always has the downside that it
hides things. Often, as in the case of garbage collection, the benefit
outweighs the cost. Too often though, people introduce magic
(aka abstraction, indirection, automation) when the benefit doesn't
justify the hiding. One should always approach magic with skepticism.
Agreed. That's why magic in software has a bad reputation. But it's not
bad if it works almost invisibly.
This is an important design principle. The "explicit is better than
implicit" is a guide, not a rule never to be broken. It's something we
should start with. Does that mean we never provide automation? Of
I suspect we're in a state of violent agreement here. :)
What you say about this in part depends on who you're talking to.
Repetition of code is generally bad. Many programmers don't abstract
*enough* and copy & paste code all over the place. We don't want to make
them more wary of automation.
To go to a related but slightly different topic:
One form of abstraction I'm still grasping for in Zope 3 is support for
coarse-grained components. When I have a whole bunch of (local)
utilities, content objects, views, permissions and the like that work
together, tied together with quite a bit of ZCML, I'd like to be able to
reuse that more easily in an application. Right now the only way to
reuse code like that I can find is to copy it and modify it, but that's
wrong - it'd like to be able to use all that code from my application
without having to copy or modify it.
For instance, for an application I needed a user and group management
system with a ZODB user interface. This uses the catalog, defines a
number of content objects and adds a bunch of views. Extracting this
functionality from the application turned out harder than I'd like it to
be. And then I haven't figured out yet how to reuse it without having to
copy and modify code...
Are there patterns to do this in current Zope 3? Part of the problem is
a dependency on local utilities - I believe the new local utility
registration API you're working on should help there. For the rest, I
guess I could just copy and rewire the ZCML, but that is quite a bit of
work and failure-prone. I could also invent a ZCML statement with a much
higher level of abstraction that takes the place of dozens of lower
level statements, but people argue against this rather a lot. What other
strategies could I employ?
Zope3-dev mailing list