[Zope3-dev] Re: reasonable syntax for multi-adaptation
Jim Fulton
jim at zope.com
Fri Sep 28 10:50:59 EDT 2007
On Sep 28, 2007, at 10:31 AM, Martijn Faassen wrote:
> Dominik Huber wrote:
>> It would be great, if we could handle other adaption-derivations
>> by the proposed unified, reasonable adaption-api too.
> [snip interesting proposal]
>
> Okay, so there seems to be quite a bit of consensus for *some* form
> of support for this. I've seen a number of proposals which to me
> look quite reasonable.
>
> Since Jim doesn't like this much but there seems to be a lot of
> support from others,
And am willing, therefore, to compromise
> we could investigate whether we can't come up with something that:
>
> * doesn't break the existing notation. The cleanest way to support
> such non-interference seems to be to do this using an extra .adapt
> method. This is unfortunate, as I at least consider it prettier if
> it used the IFoo() syntax (even though I proposed .adapt).
I agree.
>
> * creates a small a new hook inside zope.interface to support this
After thinking about it, I think I can avoid the extra hook. Don't
worry about the details. :)
>
> * can be plugged in by an optional extension, like
> zope.interfacextended
See above.
> * implements the proposed new features. I like the idea of also
> allowing utility lookup through the same mechanism.
I don't, but I'm willing to give in to popular demand.
BTW, we *could* use interface __call__ for utility lookup, as there
would be no conflict with current notation *if* we specified a
default using a keyword argument.
I would far prefer using
IFoo() or IFoo(default=None)
to look up a utility over:
IFoo.adapt() or IFoo.adapt(default=None)
for, I hope, obvious reasons.
I'd also like to support specifying a default for adapter lookup via
a keyword argument. In fact, I'd like to deprecate passing the
default positionally. This would open the door, sometime in the
future, to allowing multi-adaptation via: IFoo(ob1, ob2).
> So, any volunteers to try to implement this?
I insist on reviewing any change before checking it in. This will
create an unavoidable bottle neck.
Jim
--
Jim Fulton
Zope Corporation
More information about the Zope3-dev
mailing list