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