Jim Fulton <[EMAIL PROTECTED]> writes:
> On Sep 26, 2007, at 10:04 AM, Brandon Craig Rhodes wrote:
>
>> Instead, multi-adaption should look like this:
>>
>> IFoo(multi=(obj1, obj2))
>> IFoo(multi=(obj1, obj2), name='site_foo')
>
> Ah, using keyword arguments to get around limitations (especially
> backward compatibility issues) with the current API is a neat idea.
> If we were going to do this though, I think a method syntax would be
> cleaner. As in:
>
> IFoo.adapt([ob1, ob2], 'site_foo', None)
-1.
Unfortunately the singular verb "adapt" makes it look like normal
adaptation is what is being called for - it looks here like you are
trying to adapt a list to the IFoo interface.
Maybe ".multiadapt()"?
> Note that IFoo(ob) has some special semantics that don't apply to
> the multi- or named-adapter case.
Agreed! The semantics are different. But mightn't we simply document
this difference between single- and multi-adaptation everywhere we
need to, rather than letting it force us into splitting the adapter
syntax into two unwieldy pieces? I would not imagine that I would be
confused encountering documenting that said:
Call IFoo(x) to adapt a single object "x" to the IFoo interface,
and IBar(multi=(x,y)) to have the adapter registry find and invoke
a multi-adapter that adapts the pair of objects "x" and "y" to the
IBar interface. When performing single adaptation, the object "x"
itself is simply returned if it already offers the IFoo interface;
and if the object offers a __conform__ method, then this is called
with the IFoo interface as its argument in place of the normal
adaptation machinery.
So, I am not sure that I see yet the problem with "mixing APIs".
For me, the essential issue is that in both single- and multi-
adaptation you are returned an instance of an adapter that has been
instantiated with the objects you are adapting. Both of these
syntaxes:
IFoo(x)
IBar(multi=(x,y))
suggest this fact, even to the novice Python programmer, because they
make it look like something is being instantiated with the arguments
given, and returned. Doesn't the benefit of such clarity and symmetry
outweigh whatever slight awkwardness might exist in the sort of
documentation I suggested above?
> An added complication is that interfaces don't provide adaption
> directly, but via a hook. The existing hook api wouldn't work for
> mult or named adaptation, so a new hook would be needed.
I had assumed that IBar(multi=(obj1, obj2)) would simply dispatch to
the existing getMultiAdapter() call; how, exactly, would hooks get
involved and complicate things? Feel free to just cite a line number
and tell me to go read, all I need is a pointer to get started
understanding this.
--
Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
