[Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

[Chris McDonough]

On Thu, 2011-09-01 at 09:15 +0200, Wolfgang Schnerring wrote:
> * Chris McDonough <chrism at plope.com> [2011-08-30 03:51]:
> > On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote:
> > My interpretation of your suggestion is that maybe that "zope.component"
> > end up as what "zope.registry" is now.  But I don't think preserving the
> > name "zope.component" for this small core and spinning off everything
> > else in the package into separate bits is very attractive, because
> > "zope.component" is just a name and we can do it with a lot less churn
> > and potential for bw incompat if we just rename the core bits rather
> > than changing the meaning of "zope.component" to be "just the core
> > bits".
> 
> Yep, that's a fitting assessment.
> 
> I have two concerns, the more important one is to establish a clear
> definition of what concepts and functionality constitute the Zope
> Component Architecture (in other words, for the most part, what of
> everything that currently is in zope.component does actually belong
> there?) and to keep these core bits intact when we're extracting
> and/or pruning.
> 
> The second one is that the established package name for the ZCA has
> been zope.component, and that I'd rather keep it that way. But I guess
> I'd be willing to concede that point and take up a new name, since I
> agree that trying to keep it probably requires more churn and
> headaches than changing it.
> But I also guess I'd like the new name to be more evocative than
> "zope.registry". Yes, I fully realize the bikesheeding potential, and
> I'm sorry (a little at least ;-), but the ZCA is so much at the core
> of the Zope world I feel it deserves some consideration so as to carry
> a fitting name.
> 
> By the way, while we're taking up new names and leaving
> zope.component intact as bw compat, can we use that opportunity to
> clean up the terminology a little? For example, class Components
> should IMHO become class Registry, and getSiteManager could be
> something like getCurrentRegistry.
> 
> **
> 
> To take up the "what is the ZCA" question again, I don't know if this
> helps or confuses, but here goes: yesterday we (Thomas Lotze, Michael
> Howitz and myself) brainstormed at the office whiteboard and came up
> with stuff the ZCA is used for in Zope3-ish applications:
> 
> - Dependency Injection to promote inversion of control (utilities)
> - Multiple dispatch to promote extensibility (adapters)
> - Event handlers to promote decoupling (subscribers)
> - Plain old configuration (any of the above can be bent towards that
>   purpose, my "favourite" example being how the default view name is
>   handled... ouch.)
> - The notion of a context in which the application runs and that
>   informs its behaviour (in Zope3 terms, the "site"; more on that
>   below)
> 
> These seem to be quite different things, and I'm not certain they
> *should* be all together in one place, but on the other hand,
> extracting zope.registry as proposed seems to me to take out just
> slices of each (think "vertical stripes") and leave other parts of
> each behind in zope.component, which seems to me the wrong way around
> ("horizontal stripes" would be better).

The machinery that makes possible the first three of your "stripes"
above wind up in zope.registry in the current plan, aside from
convenience global APIs.  The fourth is a concept that doesn't really
have any code analogue.  The last would continue to be provided by
zope.component, at least for Zope, which tends to use the global
registry and various registries encountered during traversal.

> > As far as I'm concerned, the ZCA global API and zope.event machinery are
> > not "guts"; they are convenience APIs on top of the guts.  Each promotes
> > the idea that there is a single registry per process, which is not
> > always true (it's not in Pyramid, anyway).  I'd be a -1 on seeing these
> > sorts of convenience APIs come along for the ride into the "guts"
> > package, whatever that ends up being.
> 
> I don't think zope.component.getSiteManager() promotes a single
> registry per process, but rather (although maybe just as jarring) the
> concept of a "current registry".
> 
> While personally I'm not so sure anymore that this is a Good
> Thing(tm), I feel it is quite fundamental to how zope.component is
> used and thought about. If you take this notion away, of a context in
> which code runs and which provides a current registry, no more
> IFoo(bar) and no more simple getUtility, but you'll have to explicitly
> retrieve or pass around the registry.
> (I guess Pyramid does it like that? The registry lives on the request
> and that is passed around throughout the framework?)

Yes, it gets attached to the request.  We also make it available via a
threadlocal, but, by default, we don't hook getSiteManager() to make
this possible.  Instead we just maintain our own threadlocal registry
and provide an API that allows people to obtain the registry without
having a request in-hand.  Using this API is an "in case of emergency
break glass" sort of thing in Pyramid.

But in Pyramid the registry is much more an implementation detail than
it is in Zope.  The framework uses it, and developers use it indirectly
via APIs we provide, but they don't often interact with it directly;
they really don't even know it exists.  Most Pyramid developers don't
use their own adapters and utilities in their own applications, although
of course they can.    We don't support IFoo(bar) at all at module
scope, as there's no "current registry" at import time.

It wouldn't be the end of the world to have the global registry and the
global API live in zope.registry, but it doesn't help Pyramid for it to
be in there, and it probably wouldn't help anyone else either.  The
global API (which includes getSiteManager) is really just a convenience
feature, and splitting that global API across more than one package
doesn't seem to make sense to me.

It might make sense for the entire global API to be in zope.registry,
but if you take "global API" to mean what it does now that implies
dependencies on at least:

- zope.event (zope.component.event.dispatch)

- zope.testing (for addCleanUp of the global registry in
  z.c.globalregistry and other places)

It also implies conditional dependencies on zope.security (in
z.c.hooks.setSite, and other places), which are even now pretty nasty.

I'd be -1 on that if only due to the extra dependencies.

- C