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"
___
Am 03.12.2009, 14:18 Uhr, schrieb Benji York :
> 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
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
_
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
> t
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
On Thu, Dec 3, 2009 at 5:27 AM, Shane Hathaway 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
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 depre
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 tu
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 t
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
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
Lennart Regebro wrote:
> On Thu, Dec 3, 2009 at 03:14, 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(...)
>
> Change that to Martins IFoo.adapter(...) and I'm be
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.
On Thu, Dec 3, 2009 at 03:14, 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(...)
Change that to Martins IFoo.adapter(...) and I'm behind it to. :-)
It's more symmetric
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",
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 t
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 curr
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 wor
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
19 matches
Mail list logo
