On 10/16/10 2:21 CDT, Jonathan M Davis wrote:
On Friday 15 October 2010 23:35:35 Leandro Lucarella wrote:
Kagamin, el 15 de octubre a las 17:16 me escribiste:
Andrei Alexandrescu Wrote:
I was talking to Walter about Kenji's adaptTo. We both think it's a
very powerful enabler, but adaptTo is a bland name. After discussing a
few marketing strategies, I proposed "duck". It's short, simple, and
evokes "duck typing".
1. adaptTo helped me to understand what it does, while duck!Drawable
doesn't.
I agree, just "adapt" might be an option, it even has a precedence of
something similar in Python (even when the PEP[1] was rejected, PEAK has
an implementation[2]). But "duck" is really cryptic (as symbol names
invented by Andrei usually are :).
[1] http://www.python.org/dev/peps/pep-0246/
[2] http://peak.telecommunity.com/protocol_ref/module-protocols.html
Considering that no one has presented a term which makes it immediately obvious
what the function does and that the programmer is going to have to look it up
regardless, I find duck to be a far better name since you're not going to
mistake
it for anything else. Adapt can and will be used it far more contexts that duck
ever would be. duck is therefore more immediately recognizable and will not be
ambiguous to the programmer. Sure, they're going to have to look it up, but
they're going to have to look it up regardless of the name, so I think that the
shorter and more memorable is a better name.
Besides, it's good marketing. It's one thing to say, "hey, D has this
function called adaptTo that pretty much does duck typing" and a
different one to say, "gee, D has duck to enact duck typing!"
Andrei
