Naming things in Phobos - std.algorithm and writefln

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Aug 5 17:08:43 PDT 2009


Michel Fortin wrote:
> On 2009-08-05 17:40:34 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> Sergey Gromov wrote:
>>> Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote:
>>>
>>>> Michel Fortin wrote:
>>>>> In std.algorithm, wouldn't it be clearer if "splitter" was called
>>>>> "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function
>>>>> shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps?
>>>> This is a specious argument.
>>>>
>>>> splitter's only purpose is to return an instance of a Splitter struct.
>>>> You can't call it "splitLazily" or "splitLazy" because that implies 
>>>> that
>>>> the function is doing work, when it really isn't.
>>>
>>> That's if you know how it works.
>>>
>>> But if you just use these functions, it's not even remotely obvious what
>>> the difference is, and the difference in naming is so subtle that many
>>> people will be doomed to forever confuse these functions, myself
>>> included.  I confuse getopt and getopts shell functions in the same way.
>>> I simply can't remember which is which.
>>
>> Very true. If it weren't for backwards compatibility, I'd simply have 
>> split() do the lazy thing. Then array(split()) would do the eager thing.
> 
> But then I thought D2 was about making things better without worrying 
> too much about backward compatibility. I find it dubious that we are 
> ready to do a breaking language change about how properties work, but 
> when it comes to replacing some standard library functions we can't 
> because of backward compatibility. What is the criterion for an 
> acceptable breaking changes?

That's what I keep on telling Walter! That, and the fact that American 
cars suck!

Andrei



More information about the Digitalmars-d mailing list