[Zope-dev] implementing zope.component 4.0
gary.poster at gmail.com
Mon Nov 30 14:24:42 EST 2009
On Nov 30, 2009, at 11:47 AM, Martijn Faassen wrote:
> Gary Poster wrote:
>> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:
...snipping here and elsewhere without further warning...
>>> Utility lookup:
>>> Named utility lookup:
>>> Utility lookup with a default:
>> I disagree with this. More below.
>> 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
> 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
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.
>> (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.
More information about the Zope-Dev