duck!

[Andrei Alexandrescu]

On 10/19/10 17:50 CDT, Roman Ivanov wrote:
> On 10/16/2010 1:19 PM, Andrei Alexandrescu wrote:
>> The problem with "adaptTo" is that, just like itoa or printf, it is too
>> boring to have marketing value. I think the feature is going to be
>> _big_. We can't leave a big feature to a name like "adaptTo". The New
>> York Times won't have a headline like "adaptTo changes the name of the
>> game".
>
> IMO, you overestimate marketing value of function names.
>
> The paramount concern with API naming should be clarity. Reading and
> understanding code should be easy. Ideally, discussing code and
> searching for examples online should be easy too.
>
> Personally, I like when features are demonstrated by examples. The
> clearer the example, the easier it is to convince me that the
> language/API/code does something good.
>
>> This is also part of my beef with "as" or "to" for the feature. "As" is
>> difficult to talk about. "Oh my God, D has 'as'!" "Has ass?"
>
> My problem with "as" would be different. When something has a two-letter
> name (is, in, as, to, and so on) I tend to assume it's a language
> keyword, unless I know the language enough to say it's not. C# uses "as"
> for casting, for example.
>
>> I'd go with the longer "ducktype". Length is not as important as
>> evocative power and brand name!
>>
>> auto d = ducktype!Drawable(obj);
>>
>> 99.99% of programmers will have an idea of what's going on.
>
> ducktype is a bit better than duck.
>
> Hm, how about this?
>
> auto d = make!Drawable(obj);
>
> Reads "make Drawable from obj".

"make" has factory conotations. I think it's best to concede and call 
the artifact "adapt".

Andrei