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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
