To add a novice's perspective:

When I first learned Zope, I tried the syntax:

adapter = IFoo(context1, context2)

It took me hours and the help of Philipp to determine why context2 was being
returned. I saw the symmetry between IFoo(context) and a cast in other
languages and figured I'd just cast multiple contexts to an adapter. This
makes intuitive sense to the newbie. Returning the second argument as the
default adapter was strange to me, a seeming violation fo the explicit
comparisons to a cast (see the Summary on page 196 of Philipp's book, fourth
bullet point).

As a more experienced Zope developer, I never make this mistake. But I still
yearn for a simple syntax that makes multi-adaption as easy as adaption.
While IFoo.adapt() and IFoo.multiadapt() are nice, neither is as simple as

adapter = IFoo((context1, context2), default)

So, there seem to be advantages here for both the newbie and the experienced
developer. Martijn notes the advantage for the experienced; I am noting the
"it just does what I expect" simplicity for the newbie. (of course, I'd
prefer the cast syntax didn't have a default option at all, so it was really
like a cast, but what's done is done).

I don't pretend to understand Jim's objections, as I don't have that mastery
of the z3 internals. But, I plead for you all to see this from a user's
perspective, not from that of the internals. It is expected, for a user,
that adapting (context1, context2) would not return context1 as the adapter,
even if it already implements the interface, because one is attempting
MULTI-adaption. As for what is called internally, as a user of z3, I'm not
sure it matters, as long as I get the adapter back that I expect or a
default or error otherwise.

At the least, I guess, if z3 isn't going to change, the rhetoric of
comparing the adaptation syntax to a cast should change, since, to a
neewbie, the exceptions are confusing and, in my course of learning, were
not clear.


On 9/26/07, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> Hey,
> My opinions:
> It'd be nice if getMultiAdapter's functionality was in reach without
> typing: import zope.component; zope.component.getMultiAdapter. The
> IFoo() single adapter lookup shows us a way to make this possible: a
> method (in this case __call__ on the interface). It does bother me on
> occasion that I need to invoke multi adaptation in such an entirely
> different way. I must also note that it's a very common intuition to
> want to do something like IFoo((a, b)).
> Even though  my intuition is usually like Jim's and prefer to have two
> different methods, given different semantics, I consider the differences
>   in semantics here such a grey area I'm on the fence.
> That the object itself is returned if it already provides the interface
> in single adaptation is a difference in semantics, but since there's
> just no possibility of doing so in the case of multi adaptation anyway,
> you can argue whether this is a difference in semantics or not, just
> some semantics that doesn't apply. __conform__ is a bigger difference,
> but given that polymorphism abounds in object oriented code, having
> different behavior with different inputs is not *that* surprising either.
> Anyway, if we want to split methods, I'm fine with a properly named
> method for multi-adaptation on the interface. For completeness' sake
> you'd also want a properly named method on the interface for
> single-adaptation.
> IFoo.adapt() for normal adaptation
> IFoo.multiadapt() for multi adaptation
> sound reasonable to me. We then explain that if you call IFoo directly,
> IFoo.adapt is called. These could then also be extended to support named
> adapter lookup and such.
> Since Jim is -0 on his variation, he's not really against it, if someone
> else does the work, right? :)
> Regards,
> Martijn
> _______________________________________________
> Zope3-dev mailing list
> Unsub:
Zope3-dev mailing list

Reply via email to