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