duck!
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sat Oct 16 06:56:13 PDT 2010
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
More information about the Digitalmars-d
mailing list