* Chris McDonough <chr...@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 · w...@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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )