[Zope3-dev] Re: reasonable syntax for multi-adaptation

Tres Seaver tseaver at palladion.com
Wed Sep 26 21:09:37 EDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Fulton wrote:
> On Sep 26, 2007, at 3:37 PM, Dieter Maurer wrote:
> 
>> Jim Fulton wrote at 2007-9-26 15:10 -0400:
>>> ...
>>>> Jim Fulton wrote at 2007-9-26 11:29 -0400:
>>>>> ...
>>>>>>     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.
>>>> Is this not an irrelevant implementation detail?
>>> No, the specified behavior is different.
>> Hm. But "getAdapter" and "getMultiAdapter" may return "x" as well
>> (when the factory decides to do this).
>>
>> Thus, why is it relevant?
> 
> Because they don't take into account what x already provides.  They  
> will always call some factory.   Also, they never call __conforms__.

Why does the caller care?  She just wants an object which will provide
the 'IFoo' contract on behalf of the passed context.  If 'x' is capable
of providing 'IFoo' without help, then failing (or worse, returning a
less-specific factory result) when calling 'getAdapter' is the Wrong
Thing (a "least surprise" violation, if nothing else).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+wLR+gerLs4ltQ4RAuojAJ90QTKCzaEonLYPTqmJ+5SJpz1eDwCgyy4K
w59LMYo7ur+GCfEwAy+w5aM=
=Weg9
-----END PGP SIGNATURE-----



More information about the Zope3-dev mailing list