Marius Gedminas wrote:
> 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.



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to