<span class="gmail_quote"></span>To add a novice's perspective:<br><br>When I first learned Zope, I tried the syntax:<br><br>adapter = IFoo(context1, context2)<br><br>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).
<br><br>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 saying:
<br><br>adapter = IFoo((context1, context2), default)<br><br>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).
<br><br>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.
<br><br>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.
<br><span class="sg"><br>Derek</span><div><span class="e" id="q_115435ea17044e18_2"><br><br><div><span class="gmail_quote">On 9/26/07, <b class="gmail_sendername">Martijn Faassen</b> <<a href="mailto:faassen@startifact.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
faassen@startifact.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey,<br><br>My opinions:<br><br>It'd be nice if getMultiAdapter's functionality was in reach without<br>typing: import zope.component; zope.component.getMultiAdapter. The<br>IFoo() single adapter lookup shows us a way to make this possible: a
<br>method (in this case __call__ on the interface). It does bother me on<br>occasion that I need to invoke multi adaptation in such an entirely<br>different way. I must also note that it's a very common intuition to
<br>
want to do something like IFoo((a, b)).<br><br>Even though my intuition is usually like Jim's and prefer to have two<br>different methods, given different semantics, I consider the differences<br> in semantics here such a grey area I'm on the fence.
<br><br>That the object itself is returned if it already provides the interface<br>in single adaptation is a difference in semantics, but since there's<br>just no possibility of doing so in the case of multi adaptation anyway,
<br>you can argue whether this is a difference in semantics or not, just<br>some semantics that doesn't apply. __conform__ is a bigger difference,<br>but given that polymorphism abounds in object oriented code, having
<br>different behavior with different inputs is not *that* surprising either.<br><br>Anyway, if we want to split methods, I'm fine with a properly named<br>method for multi-adaptation on the interface. For completeness' sake
<br>you'd also want a properly named method on the interface for<br>single-adaptation.<br><br>IFoo.adapt() for normal adaptation<br>IFoo.multiadapt() for multi adaptation<br><br>sound reasonable to me. We then explain that if you call IFoo directly,
<br>IFoo.adapt is called. These could then also be extended to support named<br>adapter lookup and such.<br><br>Since Jim is -0 on his variation, he's not really against it, if someone<br>else does the work, right? :)
<br><br>Regards,<br><br>Martijn<br><br>_______________________________________________<br>Zope3-dev mailing list<br><a href="mailto:Zope3-dev@zope.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Zope3-dev@zope.org</a><br>Unsub: <a href="http://mail.zope.org/mailman/options/zope3-dev/derek.richardson%40gatech.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://mail.zope.org/mailman/options/zope3-dev/derek.richardson%40gatech.edu</a><br></blockquote></div><br>
</span></div>