[Grok-dev] Re: Grok component reuse in the Zope 3 world (was Re: Re: ANN: megrok.quarry)

[Gary Poster]

On May 6, 2007, at 1:09 PM, Martijn Faassen wrote:

> Hey there,

Hey. :-)

I'll again try to be brief, since I've accomplished my goal, as  
mentioned in my other email.

> Gary Poster wrote:
> [snip]
>> To be clear, the win of zcml, as I'm trying to present it, can be  
>> done without zcml--I gave the example of a separate Python file  
>> with a grok-like approach, for instance, as one of the possible  
>> replacements--
>
> As I tried to point out elsewhere, this is not a Grok-like  
> approach. I think I need to go into this idea some more, as your  
> idea sounds so simple and straightforward to apply, but it really  
> isn't.
>
> One important idea of Grok is that development agility is badly  
> hurt by this separation. Instead of having to be in one place, you  
> need to be in two places (implementation and configuration). That  
> the second place is a separate Python file or a ZCML file doesn't  
> really matter very much - I believe the fact that this second place  
> exists in the first place that's hurting agility the most, not the  
> particular spelling used.
>
> In most cases Grok actually deduces the need for registration from  
> the base class used (for a view, adapter, etc), together with some  
> class annotations (which are optional as they have defaults). Most  
> of the time in Grok-based code, configuration information cannot be  
> separated from the code that is being configured. Code and  
> configuration are actually the same thing, and that's an essential  
> characteristic of Grok's approach.

Yes, I know, and that's what I'm disagreeing with in large part, for  
shared components.  But that's fine, we've been over this. ;-)

> (note that configuration does happen at a very different stage than  
> code import or execution time - the code is introspected and  
> registrations are made during this introspection phase. This  
> actually happens during the same phase as ZCML registrations occur,  
> as it's triggered from ZCML. I.e,. this is a good idea of ZCML we  
> don't want to give up)

yay!

> Now if the need to reuse implementation and not the accompanying  
> configuration were very common, the effort to separate  
> configuration from code makes sense. I do not consider this to be  
> common, however: it's the exceptional case where you want to reuse  
> a package and not reuse its configuration. ZCML's approach to  
> enable such separate reuse, separation of configuration information  
> from the code, I consider to have a high cost in agility. That is  
> why I think we need to come up with alternative solutions, instead  
> of separation to tackle the issue of overriding or skipping  
> configuration.
>
> ZCML has some other important beneficial properties besides the  
> potential it has for reuse of code without its configuration. As I  
> already mentioned above, a concept Grok carries over is making  
> configuration happen in a separate phase. Moreover, ZCML is a  
> limited, explicit language. It makes the act of configuration very  
> clear. This really forces developers to think about the act of  
> configuration, and about what's configuration and what's not (and  
> frequently disagree, but at least think about it). This has been  
> extremely helpful.
>
> Doing configuration with Python code runs the risk a thousand  
> inconsistent API will grow and configuration code will become an  
> unpredictable mess. I think our approach with Grok has shown a way  
> to avoid those risks. Grok, for the most part, isn't expressing  
> ZCML configuration directives in the equivalent Python. It's about  
> weaving the configuration information declaratively together with  
> the actual code that it is about.
>
> Choices to separate or integrate happen frequently in programming  
> language design. Docstrings or external API documentation? Separate  
> header declarations versus deducing this from the class  
> declaration? Doctests in docstrings or in separate files? For RMI,  
> interface description languages or introspection?
>
> Related to this is explicit versus implicit - explicit static type  
> or implicit dynamic types? Explicit interfaces or informal protocols?
>
> There is no simple answer about what the right way to go is in any  
> of these cases. It depends on the circumstances. Generally the  
> choice to make something more explicit and more separate has a cost  
> in agility, with hopefully a gain in explicitness and  
> reconfigurability. The choice to integrate something tends to mean  
> a gain in agility and to reduce conceptual load on the developer.  
> There are a lot of trade-offs.
>
> Grok is in the happy position of being able to explore integrated  
> configuration information with an explicit configuration already in  
> place to learn from. We also let go of some of the benefits of ZCML  
> at the same time, hopefully to regain them, later, in a different way.
>
> It also means that the ZCML way of thinking about configuration  
> doesn't really work for Grok - applying the idea of separating the  
> code that is being configured from the configuration information  
> sounds like a relatively straightforward simple approach from the  
> perspective of someone used to ZCML. It would also, in my opinion,  
> remake Grok into something completely different.

I see.  Thanks for the explanation.

It still doesn't negate the argument for separate packages when  
appropriate, my first suggestion in the original email. :-D  This is  
similar to one of the distinctions we made in Zope 3  between zope.*  
and zope.app.*: "put your generic code, without much or any  
configuration, in zope.*, and the configuration stuff in  
zope.app.*".  While we have moved away from doing this strictly, I  
believe the rule still has some merit, as long as it is not applied  
with *too* much consistency ;-).

Gary