Naming of new lazy versions of existing Phobos functions

[Brad Anderson via Digitalmars-d]

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.

> [...]