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)


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


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)

  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 Fulton
Zope Corporation

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to