[Zope3-dev] Re: yagni on overrides?

[Martin Aspeli]

Leonardo Rochael wrote:

> If someone else presents me with an alternative zcml configuration for my
> package that was useful for their project, I can put this zcml file in my
> package for others to include when using it, instead of my default
> configuration. If there are parts in common between the default and
> alternative configuration, I'll refactor both configurations to make use of
> a common part (say, the browser cofiguration). Or maybe they're mostly the
> same except for some unwanted part (say, the subscriptions), then I can pull
> this part into a separate file that is included by my default configuration
> along with the other, more commonly used part.
> 
> A few more iterations of these refactorings and soon enough my package will
> have configuration subsets that should be useful for most users of my
> package without requiring them to copy a significant amount of my
> configuration, and without requiring them to override any part of it.
> 
> So, perhaps, we don't need powerful zcml overrides, just cooperative package
> maintainers (of which we have plenty in this community).

That assumes that (a) there are meaningful "sets" of configuration 
settings and (b) that where people want to override something, it's 
likely others will need the same overrides.

I've seen two use cases for overrides.zcml:

  - Zope 2 code needing to override Zope 3 adapters to do some Zope 
2-specific stuff.

  - Custom code that (i.e. for a specific project) that needs to change 
the behaviour of some standard component.

In the two cases above, however, I'm not sure the assumptions hold. 
Having 'configuration sets', if I understand you correctly, would mean 
keeping two sets in sync even if they only deviate slightly. That'd be 
cumbersome and risk dependency upgrades breaking things. Thus, it only 
makes sense if there is a maintainer to look after it all. But even then 
it would be cumbersome.

You could have some kind of inheritance mechanism, of course. My set 
extends your one. That's not very different from an overrides.zcml, 
though. I have two "sets of configurations by having two overrides.zcml 
files and making sure only one is in use at any one time. :)

When we *predict* the need for things to be overridden, we tend to make 
things overrideable e.g. with sensible interface modeling to allow a 
"more specific interface" override for an adapter or view, say. It's the 
unpredictable cases where overrides.zcml provides a useful safety valve.

Martin