Re: [Zope-dev] ZCA proposal
On Thursday 03 December 2009, Marius Gedminas wrote: IFoo.adapt(...) IFoo.utility(...) +1 for this. -1 for IFoo((foo, bar)). +1 from me on that too. (I'll join the bandwagon. :-) Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] ZCA proposal
On Thu, Dec 3, 2009 at 03:14, Gary Poster gary.pos...@gmail.com wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) Change that to Martins IFoo.adapter(...) and I'm behind it to. :-) It's more symmetrical with utility, as they are both nouns. But I can survive IFoo.adapt() as well. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] ZCA proposal
Martin Aspeli wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) Thinking about it a bit, it strikes me that IFoo.adapt(context) may not be right. This reads IFoo adapt context, which doesn't make sense. What I really want to hear is context adapted to IFoo. So maybe it's IFoo.adapting(context)? IFoo.adapterFor(context)? IFoo.adapter(context)? Just thinking out loud. To me, myobj.get(x) reads as myobj, please get x and give me the result, so IFoo.adapt(y) reads as IFoo, please adapt y and give me the result. That statement makes perfect sense to me. Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. To me, generic names like instance and singleton suggest we're trying to solve some grand problem that would make our brains hurt. I find it more satisfying to solve a more specific problem. I am participating in this thread because I believe the current zope.component API is unnecessarily verbose, hindering readability and adoption by Python projects that would benefit. I think adding adapt() and utility() to zope.interface.Interface might improve the situation. We could instead add adapt() and utility() functions to the zope.component package, but I haven't seen any function signature that would turn out as simple as IFoo.adapt(x). Shane ___ 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 )
Re: [Zope-dev] ZCA proposal
Lennart Regebro wrote: On Thu, Dec 3, 2009 at 03:14, Gary Poster gary.pos...@gmail.com wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) Change that to Martins IFoo.adapter(...) and I'm behind it to. :-) It's more symmetrical with utility, as they are both nouns. But I can survive IFoo.adapt() as well. Yeah, I'm not terribly fussed either way. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] ZCA proposal
Gary Poster wrote: = Why not tuple multi-adaptation in the __call__? = I'm somewhat surprised that some who have been loudest about not breaking backwards compatibility are OK with breaking this, given the two reports from the very small sample we have here of users. Do you really think introducing tuple adaptation on __call__ is risky? I don't like having two ways to look up an adapter on the interface: __call__() and adapt() = But Gary, I thought you didn't like ``adapt``? = No, I don't. I think it is a hindrance to understanding, and I would prefer ``instance``, for example (or maybe ``create``?). That said, people disagree with me. Going along with ``adapt`` but getting this new syntax gets me a lot of improvements from my perspective. I think people on the Launchpad team would be happy with this. I would explain ``adapt`` as look, it's a factory, but, oh well. Progress usually means compromise. I agree, because I think an API like instance() suggest a unification of adapter and utility lookup. :) Regards, Martijn ___ 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 )
Re: [Zope-dev] ZCA proposal
Martin Aspeli wrote: [snip] Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. Haven't you been one of the people who has maintained that changing the names would do a disservice to everybody? Regards, Martijn ___ 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 )
Re: [Zope-dev] ZCA proposal
Martijn Faassen wrote: Martin Aspeli wrote: [snip] Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. Haven't you been one of the people who has maintained that changing the names would do a disservice to everybody? Yeah, yeah, I was just thinking out loud. :) Calling the lookup method instance is not really changing the name: you'd still have utility / to register it etc. It's just the naming of a lookup method, which indicates get me the instance providing this interface. I can see it getting confusing, though. On balance, I think .utility() is better. I'm also not opposed to IFoo() for lookup (so long as registration and documentation maintains the adapter/utility distinction). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] ZCA proposal
Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I was thinking people would get behind the following proposal: IFoo() for adaptation and multi adaptation (with tuple arguments) and IFoo.utility() for utility lookups. One argument in favor of using plain calls for multi adaptation (using tuples) is that people have already discussed various alternative names to 'adapt' in just this little thread... The other argument is that we would avoid too many ways to do it. Even though I thought we had good consensus on it originally, since then I've seen an argument against a deprecation warning of implicit default on IFoo(). It is a separate discussion. I'd be in favor of it as I think the implicit default argument on IFoo() is not that common (and actually quite hard to read!), but we could easily separate that from this discussion. It would break the backwards compatibility of adapting a tuple using the adapter hook. I think that's a risk we could take. Regards, Martijn ___ 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 )
Re: [Zope-dev] ZCA proposal
For my 2 cents (not that I think anyone should care): +1 for IFoo.adapt[er](*args, **kw) and IFoo.utility(*kw) -1 for tuple adaptation on 1st arg. Besides losing genericity on tuple adaptation, we risk situations where a class could trigger multi-adaptation by inheriting from tuple. +1 for deprecating unamed default argument. Yes, this is separate from the 1st item above but if in the future we want to expand/fix the IFoo() semantics, we should start deprecating things as early as possible. Besides defalt=something is way more readable and explicitly, especially when you consider the typecasting mindset. Cheers, Leo On Thu, Dec 3, 2009 at 10:00, Martijn Faassen faas...@startifact.com wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I was thinking people would get behind the following proposal: IFoo() for adaptation and multi adaptation (with tuple arguments) and IFoo.utility() for utility lookups. One argument in favor of using plain calls for multi adaptation (using tuples) is that people have already discussed various alternative names to 'adapt' in just this little thread... The other argument is that we would avoid too many ways to do it. Even though I thought we had good consensus on it originally, since then I've seen an argument against a deprecation warning of implicit default on IFoo(). It is a separate discussion. I'd be in favor of it as I think the implicit default argument on IFoo() is not that common (and actually quite hard to read!), but we could easily separate that from this discussion. It would break the backwards compatibility of adapting a tuple using the adapter hook. I think that's a risk we could take. Regards, Martijn ___ Zope-Dev maillist - zope-...@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 ) ___ 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 )
Re: [Zope-dev] ZCA proposal
On Thu, Dec 3, 2009 at 5:27 AM, Shane Hathaway sh...@hathawaymix.org wrote: To me, myobj.get(x) reads as myobj, please get x and give me the result, so IFoo.adapt(y) reads as IFoo, please adapt y and give me the result. That statement makes perfect sense to me. Agreed. I also like adapt because it is a verb -- which I prefer method names to be. For the same reason I'm not real keen on the name utility... although I can't come up with anything better than get_utility at the moment. Too bad less-than is already defined for interfaces, otherwise we could do something crazy like IFoocontext for single adapters and IFooa, b, c for multiapdapters. I suppose we could do: IFoocontext and IFooa, b, c instead. Somehow I suspect that'll provoke a gag reflex in the most Pythonic among us as well as annoy those that want something googlable for the uninformed code reader. -- Benji York ___ 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 )
Re: [Zope-dev] ZCA proposal
On Wed, Dec 02, 2009 at 09:14:42PM -0500, Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) +1 for this. -1 for IFoo((foo, bar)). Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] ZCA proposal
Martijn Faassen wrote: I was thinking people would get behind the following proposal: IFoo() for adaptation and multi adaptation (with tuple arguments) and IFoo.utility() for utility lookups. One argument in favor of using plain calls for multi adaptation (using tuples) is that people have already discussed various alternative names to 'adapt' in just this little thread... The other argument is that we would avoid too many ways to do it. I would love to eventually have IFoo(x,y) be the equivalent of getMultiAdapter((x,y), IFoo), but I am -1 on using IFoo((x,y)) for this as that would break currently working code. (Not just theoretically, I have code in production that does this). I am +1 on using a __future__+frame hack to get IFoo(x,y) working now, but also +1 on using IFoo.adapt(x,y) or IFoo(some_keyword_arg=(x,y)) if that is more acceptable. Even though I thought we had good consensus on it originally, since then I've seen an argument against a deprecation warning of implicit default on IFoo(). It is a separate discussion. I'd be in favor of it as I think the implicit default argument on IFoo() is not that common (and actually quite hard to read!), but we could easily separate that from this discussion. +1 on deprecating us of the second positional argument as default, even if the signature is otherwise unchanged. It would break the backwards compatibility of adapting a tuple using the adapter hook. I think that's a risk we could take. I disagree, breaking backwards compatibility in this particular way would hurt several projects I am involved in. - Jacob ___ 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 )
Re: [Zope-dev] ZCA proposal
Jacob Holm wrote: [snip] I disagree, breaking backwards compatibility in this particular way would hurt several projects I am involved in. Okay, understood. So I'll go with .adapt() and .utility() and deprecate implicit default argument. Regards, Martijn ___ 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 )
Re: [Zope-dev] ZCA proposal
Am 03.12.2009, 14:18 Uhr, schrieb Benji York be...@zope.com: Agreed. I also like adapt because it is a verb -- which I prefer method names to be. For the same reason I'm not real keen on the name utility... although I can't come up with anything better than get_utility at the moment. I've been struggling with this as well. I think the linguistic quandary is similar to the adapter/utility (non-)unification stuff. There is great value in saying that method names *should* be verbs. Alternatives might be IFoo.return() (is this doable?) IFoo.issue() (like library books), or IFoo.use() (because I can't bring myself to use utilise) However, there is probably more value in consistency with the terms as used in the API. It's been a very interesting discussion for me as I don't spend that much time coding. Regarding introducing non-zopers to this stuff: I've found that both Philip von Weiterhausen and Martin Aspeli do make this stuff easier to understand assuming you've got some kind of application context. But we do need to evangelise this stuff better! @Chris - Are you referring to the interface specification/marker duality? If so, I agree that this is definitely a conceptual pothole and most of the use I've seen is of interfaces as markers (smartcards). Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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 )
[Zope-dev] ZCA proposal
I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) = Why? = - This is a significant improvement in terms of being memorable, as far as I'm concerned. It's also briefer, which is related. - It uses the terms we've already taught. - It is entirely backwards compatible. We don't have to poll the world and hope we didn't miss anyone. - We can make the call syntax for ``adapt`` take multiple arguments. - It is symmetric-ish. - It would potentially allow a place to hang debug/analysis calls, as I showed earlier, but let's not have that debate yet. I can put those somewhere else if I need to. = Why not tuple multi-adaptation in the __call__? = I'm somewhat surprised that some who have been loudest about not breaking backwards compatibility are OK with breaking this, given the two reports from the very small sample we have here of users. I think it is unnecessarily risky for minimal gain, particularly when we have another reasonable option. = But Gary, I thought you didn't like ``adapt``? = No, I don't. I think it is a hindrance to understanding, and I would prefer ``instance``, for example (or maybe ``create``?). That said, people disagree with me. Going along with ``adapt`` but getting this new syntax gets me a lot of improvements from my perspective. I think people on the Launchpad team would be happy with this. I would explain ``adapt`` as look, it's a factory, but, oh well. Progress usually means compromise. = But Gary, I thought you didn't like ``utility``? = No, I don't. I already gave up on that one, since I didn't have an answer better than singleton and I acknowledge that it is not great (either, for different reasons). 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 )
Re: [Zope-dev] ZCA proposal
Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I could get behind this too. We'd need the current IFoo(context, default) for single adaptation to continue to work, and I *wouldn't* deprecate it with a warning, since it'd just lead to a lot of warnings. We'd obviously also want the existing get*() methods to continue to work. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] ZCA proposal
On Dec 2, 2009, at 11:09 PM, Martin Aspeli wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I could get behind this too. We'd need the current IFoo(context, default) for single adaptation to continue to work, and I *wouldn't* deprecate it with a warning, since it'd just lead to a lot of warnings. We'd obviously also want the existing get*() methods to continue to work. Not sure which get* you mean (get* and query* in ZCA?) but generally agree that we are talking about adding, not removing. 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 )
Re: [Zope-dev] ZCA proposal
Gary Poster wrote: On Dec 2, 2009, at 11:09 PM, Martin Aspeli wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I could get behind this too. We'd need the current IFoo(context, default) for single adaptation to continue to work, and I *wouldn't* deprecate it with a warning, since it'd just lead to a lot of warnings. We'd obviously also want the existing get*() methods to continue to work. Not sure which get* you mean (get* and query* in ZCA?) but generally agree that we are talking about adding, not removing. Sorry, yeah - getMultiAdapter(), getAdapter(), getUtility() and their query equivalents. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] ZCA proposal
Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) Thinking about it a bit, it strikes me that IFoo.adapt(context) may not be right. This reads IFoo adapt context, which doesn't make sense. What I really want to hear is context adapted to IFoo. So maybe it's IFoo.adapting(context)? IFoo.adapterFor(context)? IFoo.adapter(context)? Just thinking out loud. Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
