[Zope-dev] implementing zope.component 4.0

[Gary Poster]

On Nov 30, 2009, at 11:47 AM, Martijn Faassen wrote:

> Hey,
> 
> Gary Poster wrote:
>> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:

...snipping here and elsewhere without further warning...

>>> Utility lookup:
>>> 
>>> IFoo()
>>> 
>>> Named utility lookup:
>>> 
>>> IFoo(name="foo")
>>> 
>>> Utility lookup with a default:
>>> 
>>> IFoo(default=bar)
>> 
>> I disagree with this.  More below.
> 
> [snip]
>> As a matter of mechanics, when you register something we call an
>> adapter, it is a callable that takes one or more arguments.  If we
>> were going to follow the pattern that Marius laid out to establish
>> what happens when, then we have this, roughly:
>> 
>> register callable that takes two arguments: IFoo(bar, baz)
>> 
>> register callable that takes one argument: IFoo(bar)
>> 
>> register callable that takes no arguments: IFoo()
>> 
>> If instead we have the last step as what is proposed here
>> 
>> register non-callable IFoo()
>> 
>> then I think that breaks an important pattern for usage
>> understandability.
> 
> I still don't see why that isn't an implementation detail. How we get an 
> IFoo doesn't concern us when we're calling it, as long as we get an 
> IFoo? Even with adaptation a singleton could be returned; it's just the 
> implementation of such would be different.

The people I know are involved in both registration and usage of these things.

> If we take Marius' pattern, registring a singleton directly would simply 
> be a shortcut API for registring a factory for utilities. (Utility 
> factories would make it easier to implement local utilities that aren't 
> ZODB-backed...)

Make those factories that do not take arguments.  That's the use case for IFoo().

> 
>> That is, IFoo() can have a semantic if that is valuable, but it is
>> not the same as registering and getting non-called singletons.
> 
> What is this valuable semantic?

Marius said he has had a use case.  It sounds like you gave one above.

> 
> [snip]
>> (To be complete, I am in favor of ditching "subscription adapters" in
>> favor of other mechanisms related to named singleton lookups.)
> 
> I really need to think through subscription adapters; I haven't done any 
> analysis about those.
> 
>> 2) The term "utility" is another barrier to understandability.  They
>> are singletons.  Explaining them as such is a "well, why didn't you
>> say so" experience.
> 
> Another way to explain utilities is that getting a utility is a lot like 
> importing something in Python, except that what is imported is pluggable 
> and the required interface is specified explicitly.
> 
>> Therefore, I am in favor of removing the necessity to use the word
>> utility.  That said, they are not factories.  They should not be
>> mixed with the two.  My preference for future changes is to have an
>> API using the ``singleton`` name.  
> 
> "import by interface" to me sounds like it'd clarify matters for more 
> Python programmers. Singleton has all kinds of design pattern 
> connotations that don't really apply here.
> 
>> Moreover, I think that some of the
>> use cases that Marius referred to for underpowered "utilities" coud
>> be remedied by having a utility/singleton lookup that allowed looking
>> up by required values like the adapter/factory lookup.
> 
> I don't understand. Could you rephrase?

Right now you can only look up a utility with a desired output, and optional name.  Is it useful to also be able to pass in a context of objects for the lookup (the "required" values in the underlying implementation)?

> 
>>> Features off the table for now -------------------------------
>>> 
>>> Saying an interface is implemented by a class (Python 2.6 and up)
>>> with a decorator we'll leave out of the discussion for now.
>>> 
>>> It would also be come up with an improved API to look up the
>>> adapter *before* it is called, but I'd also like to take this off
>>> the table for this discussion.
>> 
>> It seems to me that this, along with the documentation call that
>> Chris gave, is a much more valuable immediate effort.  One of the
>> biggest complaints I heard was with debugging.  I've spent some
>> thought on the debugging story, and have some APIs sketched out in my
>> experiments--it was one of the first things I worked on.  To do it
>> cleanly (the way I envision) would require some work, but a first cut
>> wouldn't be too bad.
> 
> Hm, I disagree about what's more valuable.

Sure; we have different perspectives on who we are aiming for.  You have said you are not aiming for new/non-expert users, at least in this round.  In contrast, they are my primary clients.

Gary