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".
