[Zope-dev] implementing zope.component 4.0
Martijn Faassen
faassen at startifact.com
Fri Nov 27 10:25:44 EST 2009
Marius Gedminas wrote:
[snip]
> The "utilities must be singletons" logic hardcoded in the ZCA.
>
> provideAdapter(factory, adapts=(one, two, three))
> provideAdapter(factory, adapts=(one, two))
> provideAdapter(factory, adapts=(one, ))
>
> The natural progression, to me, is
>
> provideAdapter(factory, adapts=())
>
> rather than
>
> provideUtility(singleton)
>
> If we decide, ignoring BBB concerns, to make
>
> provideUtility(singleton, provides=IFoo)
>
> be equivalent to
>
> provideAdapter(lambda: singleton, adapts=(), provides=IFoo)
>
> then I'd be very happy to use
>
> IFoo()
>
> for utility lookup.
>
> This also assumes that I'm free to
>
> provideAdapter(arbitrary_callable, adapts=())
>
> and use computed-utility-lookup, or even create utilities on demand in
> my arbitrary_callable.
>
> Three cheers for utility and empty-tuple-adapter unification!
This sounds appealing to me.
Making it so should be seen as a separate project. The backwards
compatibility implications are rather larger, especially in the face of
persistent registrations..
Someone would need to experiment whether zope.component.registry can be
refactored into these terms. Effectively we'd merge
_utility_registrations into _adapter_registrations. But how would this
impact the performance of things like 'registeredUtilities()', for instance?
I wonder too what we could do to subscription_registrations and
handler_registrations, I hadn't considered those in these discussions at
all yet.
Regards,
Martijn
More information about the Zope-Dev
mailing list