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
