[Zope3-dev] what is ZCML?

Jim Fulton jim at zope.com
Wed Mar 15 07:29:23 EST 2006


Martijn Faassen wrote:
> Shane Hathaway wrote:
> 
>> Jim Fulton wrote:
>>
>>> Shane Hathaway wrote:
>>>
>>>> +1.  When I learn a skill, it is at first completely explicit, and 
>>>> as the skill becomes predictable and reliable, it gradually becomes 
>>>> implicit.  If I kept everything explicit, I would hinder myself from 
>>>> building higher level skills.
>>>>
>>>> So explicit is better than implicit until a sufficiently tight 
>>>> abstraction comes about.  Take memory management: yesterday it was 
>>>> explicit (malloc/free); today it's mostly implicit (garbage 
>>>> collection). Garbage collection is both an abstraction, since 
>>>> programmers no longer manage memory directly, and an indirection, 
>>>> since programmers now use APIs that call malloc and free.  We all 
>>>> agree GC is good, so explicit is definitely not always better than 
>>>> implicit.
>>>
>>>
>>> Thanks for explaining "Explicit is better than implicit,
>>> except when it's not."
>>
>>  
>> Admittedly, I should have posted that in my blog, not here. :-)
> 
> 
> 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.

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.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Zope3-dev mailing list