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
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
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
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
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
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
On Thu, Dec 3, 2009 at 5:27 AM, Shane Hathaway <shane@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 IFoo<context> for single adapters and IFoo<a, b, c> for multiapdapters. I suppose we could do: IFoo<<context>> and IFoo<<a, 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
Am 03.12.2009, 14:18 Uhr, schrieb Benji York <benji@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
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
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
On Thu, Dec 3, 2009 at 03:14, Gary Poster <gary.poster@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
Lennart Regebro wrote:
On Thu, Dec 3, 2009 at 03:14, Gary Poster <gary.poster@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
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
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
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 <faassen@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-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 )
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
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
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
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"
participants (11)
-
Benji York -
Charlie Clark -
Gary Poster -
Jacob Holm -
Lennart Regebro -
Leonardo Rochael Almeida -
Marius Gedminas -
Martijn Faassen -
Martin Aspeli -
Shane Hathaway -
Stephan Richter