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