On Friday, 18 July 2014 at 20:35:33 UTC, Walter Bright wrote:
General comment (not particularly directed at Tourist):
There is no such thing as the perfect set of names and the
perfect naming convention. These discussions about which of
"car", "auto", "vehicle" is more intuitive give the illusion of
sage discussions on issues of note, but are really just
bikeshedding. There is no correct solution, and no possibility
of consensus. Coding styles and best practices also change,
making earlier name choices seem quaint, but that still doesn't
justify renaming them all to the latest fashion.
There is no renaming being proposed. I don't know why the idea of
renaming keeps being brought up. This is not related in any way
to the phobos renaming that has traumatized you in the past.
I can't understand any user caring if a function is named
"setExt" or "setExtension" or "withExtension". It's more like
he needs a function that sets a filename extension, he finds
it, uses it, and moves on.
It's kind of weird that you'd say that because you seem to be
pretty strongly opinionated about the naming.
What matters is what setExt() actually does, which is provide a
lazy algorithm designed to be composable and not make decisions
about how needed memory is allocated, thereby providing maximum
flexibility and utility to the user.
I agree and we kind of discovered elsewhere in this thread that
setExtention is actually kind of an odd-man-out. Most functions,
especially in std.string, have pretty obvious names to use so
this thread as mostly just resulted in some good ideas for how to
approach the necessary new names on a case-by-case basis so it's
been valuable.
I find these interminable naming threads to be frustrating and
an impediment to progress on issues with Phobos that actually
matter, like making Phobos usable for people who don't want to
use the GC.
The idea of creating this thread was to address the one remaining
problem and get your stalled pull request merged. It seemed
appropriate to bring up the issue since your pull request is the
prototype for the effort and is something every other lazifying
pull request will have to consider. I wanted to make it so we
wouldn't have to bicker about naming with every pull request that
comes in by trying to head off that problem at the pass.
My bias is to give strong preference in names to the choice of
the person who actually wrote the code in question.
That's really no way to write a standard library. The naming
should be just as open to review as the implementation. People
care a bit too much about naming but caring too little is also a
problem. Intuitive naming is a valuable thing to have. Nobody
wants to be constantly looking up function names because it's
just a roll of the dice how the name ended up.
[...]