Martin Aspeli wrote: > Hi Chris, > > Chris McDonough wrote: >> Martin Aspeli wrote: >>> We need to make sure that we're not inventing a different way to achieve >>> something which is already possible. This will lead to confusion, >>> because people will have to know "which way" is applicable in a given >>> situation, and the distinction will seem arbitrary. >> I fear we are indeed inventing a different way to achieve something which is >> already possible. We aren't doing it arbitrarily, though: the current way >> just >> requires the use of an interface instead of a string. Interface usage for >> such >> a simple pattern implies a cognitive load that appears to exceed the pain >> point >> of most Python developers who are not already familiar with Zope. So we'd >> like >> to ameliorate that as best we can. > > I wish I knew what "ameliorate" meant, but I'm sure I agree.
Ha, sorry, I've been writing documentation and trying to sound smart. "fix". ;-) > My concern is that we also have a pretty large existing user base to > worry about, and we wouldn't want to confuse them. Or, indeed, new users > confronted with code that has been written up to this point. Right. I don't think there's any way we could further confuse existing users: there aren't really any existing docs for the``zope.component.registry.Component`` object which would reinforce a set of expectations that would exclude use of a dict API against it. As far as I can tell, existing user-consumable documentation documents the threadlocal API only. (I am beginning to think the broadness of the threadlocal API is itself a problem, but that's another issue entirely.) New users confronted with old code: well, we already have this problem, and at least if we make incremental improvements like this one, we have a shot at making existing code more readable. > I think it would be nicer, because we could tell a story like this: > > - if you just want a place to store things by name... > - ... which can be overridden at runtime or customised with local > components ... > - ... and you don't care too much about the notion of an interface ... > - ... then here's the ZCA way to look up a component by name only > > To register: > > reg = getSiteManager() > reg['rootfactory'] = MyRoot() > > To retrieve: > > reg['rootfactory'] > > To delete: > > del reg['rootfactory'] > > > The equivalent ideas would be: > > reg.registerUtility(MyRoot(), provides=Interface, name='rootfactory') > getUtility(Interface, name='rootfactory') > reg.unregisterUtility(provides=Interface, name='rootfactory') > > Although I suspect we want a marker interface that's a bit more specific > than just 'Interface' since we already have some things that register > interfaces as utility, I think. So maybe: > > class IAnonymousUtility(Interface): > pass Yup, +1 on all that if it would mean the registry object got a complete dict API (although I think we'll need to fix the "name must be a string" issue I sent earlier). To be honest, I'm not really sure that this pattern has much practical benefit over inheriting from dict, because it just means more (missing ;-) ) documentation, but I recognize the desire for "internal consistency". - C _______________________________________________ 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 )