Tres Seaver <[EMAIL PROTECTED]> writes:
> Martijn Faassen wrote:
>
>> IFoo.adapt() for normal adaptation
>> IFoo.multiadapt() for multi adaptation
>
> I'd rather have 'adapt' take *args for the contexts, and keywords
> for extras (like name).
And you could make the "default=" another possible extra! In which
case our proposals at the moment compare something like this:
Brandon
Utility? IFoo()
Single adaptation IFoo(a)
... with default IFoo(a, default=y)
Multi adaptation IFoo(multi=(a,b))
... with default IFoo(multi=(a,b), default=y)
Named multi adapter IFoo(multi=(a,b), name='z')
... with default IFoo(multi=(a,b), name='z', default=y)
Martijn/Tres
Utility IFoo.adapt()
Single adaptation IFoo.adapt(a)
... with default IFoo.adapt(a, default=y)
Multi adaptation IFoo.adapt(a,b)
... with default IFoo.adapt(a,b, default=y)
Named multi adapter IFoo.adapt(a,b, name='z')
... with default IFoo.adapt(a,b, name='z', default=y)
Well, I have to admit, yours are a lot prettier. The word "adapt"
takes no more characters than my "multi", and parenthesis disappear!
And though I might quibble that "adapt()" would be better spelled
"utility()", there is a nice symmetry about your idea.
- Both patterns make it explicit to anyone reading the code when a
default value is being passed, which should vastly reduce surprise.
- Mine feels more natural and Pythonic to people who, like PvW in his
book, think of adaptation as being like casting.
- On the other hand, adaptation is *not* casting, and having to spell
out "adapt" really makes for explicit code! And the very natural
handling of single or multiple *args in your scheme is very pretty.
- My scheme requires the coder to remember that multi-adaption is
"done differently" than normal adaption; yours does not.
- My scheme, by requiring the magic keyword "multi=", leaves the user
in the same dratted danger as before - that he will call IFoo(a, b)
and think that he's multiply adapting!
Given those last two points, I must abandon my earlier proposal and
respond to that of Martijn and Tres with:
+1
--
Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
