On 6/26/2015 5:04 AM, Tofu Ninja wrote:
> On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev wrote:
>> So, one option is to stay consistent with these additions, and go with
>> upperCaser and lowerCaser, even if those sound a bit odd.
>
> Why not upperCaseSetter/lowerCaseSetter? Bit longer but upper case and
> lower case don't have a good noun version. Personally
> upperCaser/lowerCaser sound really bad to me, though I like the idea of
> keeping it a noun because that matches every thing else.

I think upperCaser and lowerCaser are just fine. And I'm saying that as someone who has been teaching English in Korea for a couple of decades :) No, these aren't words we would normally use. But a couple of points.

1. An -er suffix is immediately recognizable in most cases as "a thing that takes an action." Native English-speaking children and, in my experience, non-native speakers often tack it on to verbs to create a "doer" noun even when a different word already exists. A great example is "cooker" to refer to a "cook". It's well-understood from that perspective.

2. English is full of broken conventions, making it more onerous to learn vocabulary than it ought to be. I think we should pick an easily-understood convention that fits the usage of whatever category of functions we're dealing with and stick with it as zealously as possible, even if it means using words that aren't part of the language or that don't look so pretty when they are strung together. Doing so makes it much easier to reason at a glance about what's going on.

upperCased/lowerCased work fine for strings that have already been transformed, but ranges that carry out the transformation are more accurately named upperCaser/lowerCaser. IMO, that's the simplest, most self-descriptive name these functions could have.

> IMO, when naming things, generally we should lean towards representing semantics rather than mechanics (i.e. how is this function going to be used, rather than what this function does under the hood), as that will result in more readable code.

+1

On Thursday, 25 June 2015 at 19:22:16 UTC, Steven Schveighoffer wrote:
> On 6/25/15 2:37 PM, deadalnix wrote:
>
>> I can do another PR to change the name. Let's already get the TupeTuple
>> in the old module and remove it from std.meta so at least this
>> monstrosity stay contained.
>
> Well, we should at least have the documentation for std.meta not referring to a symbol that doesn't exist there.
>
> -Steve

And https://github.com/D-Programming-Language/phobos/pull/3463

We can discuss the details in the PR.

On Thursday, 25 June 2015 at 21:01:39 UTC, Vladimir Panteleev wrote:
> writeln(str.lowerCased.detabbed.transmogrified);
>
> sounds better than this:
>
> writeln(str.lowerCaser.detabber.transmogrifier);
>
> IMO, when naming things, generally we should lean towards representing semantics rather than mechanics (i.e. how is this function going to be used, rather than what this function does under the hood), as that will result in more readable code.
>
> Anyway, this is extreme bikeshedding and I won't mind too much leaving these alone.
>
> Proposed new names: entabbed, detabbed, left/right/centerJustified, soundexed. (Existing similar names: `indexed`, `transposed`)

They're nicer without either 'er' nor 'ed'.

writeln(str.lowerCase.detab.transmogrify);

Just as join and split are much better than the rather tortured joiner and splitter. That may be a cutter but I want it to cut, and would rather invoke it that way. The er and ed carry no useful information and sound clunky. A man may be a mower but I'd ask him to mow the field.

On Thursday, 2 July 2015 at 08:48:42 UTC, ixid wrote:
> They're nicer without either 'er' nor 'ed'.
>
> writeln(str.lowerCase.detab.transmogrify);
>
> Just as join and split are much better than the rather tortured joiner and splitter. That may be a cutter but I want it to cut, and would rather invoke it that way. The er and ed carry no useful information and sound clunky. A man may be a mower but I'd ask him to mow the field.

Well, for one, splitter and joiner don't do any splitting or joining - they simply return a range type which does so as you iterate over it, so that "er" is actually very related to what they're doing, and split and join would arguably be misnomers, since that implies that they actually split or join the input (which they don't). On the other hand, the split and join functions - which are eager - very much deserve their names, since the _do_ split and join their input respectively.

And for two, in the cases of the new functions that have been added recently which triggered this discussion in the first place, eager versions already exist which have verb names like you're looking for, so we have to use new names even if we wanted to use names like you're suggesting. So, if we were going to just use verbs like before, we'd have to come up with completely new names. And when splitter and joiner were added, split and join already existed, so new names were needed. So, we already have a precedent for adding "er" for functions which return lazy ranges, and it makes perfect sense to do so given that they're simply returning objects which do the action rather than doing the action themselves. They're actually more like constructors than normal functions.

- Jonathan M Davis

On Thursday, 2 July 2015 at 11:04:52 UTC, Jonathan M Davis wrote:
> eager versions already exist which have verb names like you're looking for, so we have to use new names even if we wanted to use names like you're suggesting. So, if we were going to just use verbs like before, we'd have to come up with completely new names. And when splitter and joiner were added, split and join already existed, so new names were needed.

I suppose my thought process is: terse but clear names like the original verbs are superior. The default assumption should be shifted from eager to lazy for how functions behave. Therefore we should use the best names with what we regard as the best functions.