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 _______________________________________________ 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 )
