Michel Fortin wrote:
On 2009-08-05 17:40:34 -0400, Andrei Alexandrescu
<[email protected]> 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
