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
course not.

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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to