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

[Wolfgang Schnerring]

* 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).

> 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?)

Wolfgang

-- 
Wolfgang Schnerring · ws at gocept.com · software development
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting