Joachim König wrote: > Martin Aspeli wrote: >> Clearly, it could. But that's not the way we went. Changing it now would >> be really damaging, and I'm not sure what would be gained. >> >> I can imagine use cases where getting a new instance each time would be >> useful. > But that is under the full controll of the __call__ of the utility, it > could return whatever > it wants, as long as what it returns implements the requested interface > of course ( > imagine a pool of utilities implementing the interface, some being "busy")
I wouldn't want to force everyone to implement def __call__(self): return self Since this is the most common (and current) use case. And ignoring BBB is not an option. :) Nor would I want some separation of factory and object where everyone had to implement both. > If you'd like to check (as a user of the ZCA) if you got a singleton for > a utility, > then compare the lookup() against the utility returned, e.g. __call__ > returned self. You wouldn't. > The distinction between utility and adapter only burdens the ZCA with > no gain. The > only reason for ZCA to know about it today is to decide if to return the > registered > object or to call it. And a lot of discussion is necessary to explain > the difference. I disagree. I think it may burden the internal implementation of the ZCA. I don't think it that's the correct perspective, though. I think that logically, these are two different concepts that meet two different sets of use cases. I think there'd be *more* documentation required to explain how one super-general concept stretches to a dozen different use cases, than to explain how two concepts stretch to half a dozen each in two broad categories. See my reply to Martijn for more detail. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book _______________________________________________ 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 )