[Zope-dev] Interfaces vs ZCA concepts

[Martijn Faassen]

Marius Gedminas wrote:
[snip]
> So I'm -99 for magical side effects of import statements, but thankfully
> the community opinion is already against them.

Yeah, I was a bit too cavalier in earlier discussions about such a 
solution. Tres suggested having a proper plugin API for this and a 
registration function, and I agree. This should be called early in the 
startup sequence but not during import time.

> I'm -0 for having an implementation that seems to be working, but
> isn't (utility lookup when no utilities can possibly be defined?  very
> useful, that), unless you invoke some magical incantation.
> 
> It's only -0 rather than something stronger because the same sort of
> situation already exists with Interface.__call__ hook, and it doesn't
> cause any problems in practice (probably because everybody calls
> placelessSetUp() at the start of their test setUp).

I see this as a bootstrapping issue as we're fiddling with the component 
architecture itself.

Normally when I want to provide a plugin API for a library I'd look into 
using adapters or utilities. The library would look these up, and 
external systems have to provide them. If they don't, it won't work 
(ComponentLookupError) or alternatively the library falls back on 
default behavior. Such a design pattern I dare say is fairly accepted 
within the user community of the ZCA. :)

But since we are bootstrapping the component architecture itself, we 
have to come up with an alternative implementation. We instead offer a 
registration API in zope.interface and we have zope.component register 
the appropriate plugin.

We then modify the startup procedure to tell zope.component to register 
itself with zope.interface, and we modify the testing infrastructure 
provided by zope.component to do the same thing. As you say something 
very similar is going on with the traditional adapter hook already.

Regards,

Martijn