Re: Re: reasonable syntax for multi-adaptation

On Sep 26, 2007, at 11:08 AM, Brandon Craig Rhodes wrote:

> 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 don't consider either unwieldy.

...

> So, I am not sure that I see yet the problem with "mixing APIs".

The semantics of the call would change in fundamental ways based on  
the arguments passed. I think this is very bad.  If you disagree,  
sorry. :)


> 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))

Actually, that is not the case.  If x already provides IFoo, then in  
the first case, the existing object is retuned. Nothing is  
instantiated.  OTOH, in:

   getMultiAdapter([x], IFoo)

or
   getAdapter(x, IFoo)

either there is an error or some factory will be called.  x won't be  
returned unless the factory happens to return it.

...

>> 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.

zope.interface does *not* depend on zope.component.  It only does  
adaptation the way it does because it provides a hook that  
zope.component fills.  Other people are using zope.interface with  
different adaptation schemes.

Adding multi- or named- adaption support would require a similar hook.

I don't really have time to continue this discussion.  You made a  
reasonable proposal, but for various reasons I've tried to explain, I  
don't support it.

Jim

--
Jim Fulton
Zope Corporation