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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
