[Zope-dev] implementing zope.component 4.0

[Martin Aspeli]

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