[Zope3-dev] Re: what is ZCML?

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Fulton wrote:
> 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.

I wonder if there isn't a sore spot which is driving a lot of the
discussion here, but isn't being mentioned:  the experiment in form
definition (browser:addform / browser:editform).  The interesting thing
about that experiment is that it *almost* worked, as magic;  its failure
was not in what it made easier (generating a view from a schema *and* a
policy), but in what it made harder (changing the behavior of the
generated view).

Developers who are the only admins for the sites they deploy are *not*
representative of the intended audience for ZCML;  they are much more
comfortable with "back to Python" as a solution than more traditional
admins / integrators would be.  "Big" directives, with clearly
documented knobs for specifying policies, are likely to appeal more to
folks sho are *not* inclined to write Python.

The fact that such developer-admins are the primary users of ZCML so far
is due to the small size of the Zope3 market to date.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEGD5f+gerLs4ltQ4RAnCjAKDb/6AM4phxLZhHnSPH554Ysv8CIwCfRIUo
8+DrkkvhQFQDB8WGCSC70j4=
=X/7J
-----END PGP SIGNATURE-----