[Zope3-dev] Re: reasonable syntax for multi-adaptation
Martijn Faassen
faassen at startifact.com
Fri Sep 28 11:14:13 EDT 2007
Hey,
First: thanks for listening, Jim.
On 9/28/07, Jim Fulton <jim at zope.com> wrote:
[snip]
> > 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.
Hm, you agree with my evaluation, but would this mean you'd suggest we
use 'adapt' or extend the __call__ syntax?
> > * 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. :)
Cool! The person that tries to implement this will have to worry about
them, though, so we'll get back to you on that, I'm sure.
> 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.
Agreed. This is good argument for using the __call__ syntax.
> 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).
+1
> > 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.
Understood. Work will be done on a branch.
Do you suggest we extend zope.component with support for this, or
would you suggest we indeed create a new package?
Regards,
Martijn
More information about the Zope3-dev
mailing list