June 25, 2015
On 6/25/15 3:57 PM, Vladimir Panteleev wrote:
> On Thursday, 25 June 2015 at 19:55:41 UTC, Steven Schveighoffer wrote:
>> Yeah, I agree for existing names, but these are unreleased new names.
>
> I thought the idea was to use this trick to avoid introducing the new
> names, and instead change the established names in a
> mostly-backwards-compatible way.

To be clearer, my change would remove the newly-added toExt. I don't consider this a breakage since it wasn't released. Instead, we would rewrite toExtension to do what toExt does, but in a backwards compatible way.

-Steve
June 25, 2015
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.
June 25, 2015
On 06/25/2015 04:10 PM, Vladimir Panteleev wrote:
>
>
> And, IMHO, this:
>
> fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
>
>
> looks much better than this:
>
> fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
>

Definitely. The existing functions should have been named 'joined' and 'splitted'. :o)
June 25, 2015
On Thursday, 25 June 2015 at 20:41:13 UTC, Timon Gehr wrote:
> On 06/25/2015 04:10 PM, Vladimir Panteleev wrote:
>>
>>
>> And, IMHO, this:
>>
>> fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
>>
>>
>> looks much better than this:
>>
>> fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
>>
>
> Definitely. The existing functions should have been named 'joined' and 'splitted'. :o)

I actually hypothesize that "joiner"/"splitter" were chosen because "split" the verb's past tense is also "split", which was taken by the eager function.
June 25, 2015
Please, no code breakage because of renaming.
June 25, 2015
On 06/25/2015 04:24 PM, Jonathan M Davis wrote:
> On Thursday, 25 June 2015 at 13:35:30 UTC, Vladimir Panteleev wrote:
>> On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
>>> http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff
>>>
>>
>> Rationale:
>>
>> - The eager versions are called absolutePath, normalizedPath,
>> relativePath. If anything, the current naming scheme is opposite to
>> some options we've been discussing (e.g. eager=toLowerCase,
>> lazy=lowerCase[d|r]).
>>
>> Suggested new names: asAbsolutePath, asNormalizedPath, asRelativePath.
>>
>> Couldn't think of anything better, but I think this is an improvement.
>> If we are to adopt the "as" prefix, we could also go with
>> asLowerCase/asUpperCase for the std.uni ones.
>
> That seems like a reasonable idea for the cases where we really don't
> have a noun to act as the one doing the action. The situation is weird
> enough with uppercase and lowercase, since you end up with stuff like
> upperCaser and lowerCaser when caser isn't really a thing, but at least
> there, we at least have a fake noun that makes sense. For the path ones,
> I don't see any kind of noun that makes sense. So, asAbsolutePath, etc.
> definitely makes some sense, so maybe asLowerCase and asUpperCase would
> make more sense too. In general though, I'd prefer that we go with the
> noun naming scheme - particularly when they're basically constructors
> for ranges. But it obviously doesn't work in all cases.
>
> - Jonathan M Davis

pathAbsolutizer, pathNormalizer, pathRelativizer. :-)
June 25, 2015
Also, making PRs for this is fine, but please hold off on pulling until Andrei is back and can check.
June 25, 2015
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
> http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff

So, there is some discussion about these here already:

http://forum.dlang.org/post/ubfmdrorjtasgeungfin@forum.dlang.org

There seems to be varying opinion, so I'm going to formally nominate them for renaming and get more opinions.

Rationale:

The merits of the verb-noun form ("xxxer") is that there exists precedent (`joiner` and `splitter`), and that they do a good job at describing what actually happens under the hood.

The downside is that they simply don't sound as good as some of the other options when using it in the code. To reiterate on a point from an earlier post, I think that this:

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`)

June 25, 2015
On Thursday, 25 June 2015 at 20:55:36 UTC, Walter Bright wrote:
> Also, making PRs for this is fine, but please hold off on pulling until Andrei is back and can check.

Do you know if Andrei will be back before RC1 (or the release, at least)? Missing the release defeats the entire point of this thread, and holding up the release because we need Andrei's permission to rename a few functions and he is moving seems rather silly as well.

June 25, 2015
On 06/25/2015 10:42 PM, Vladimir Panteleev wrote:
> On Thursday, 25 June 2015 at 20:41:13 UTC, Timon Gehr wrote:
>> On 06/25/2015 04:10 PM, Vladimir Panteleev wrote:
>>>
>>>
>>> And, IMHO, this:
>>>
>>> fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
>>>
>>>
>>>
>>> looks much better than this:
>>>
>>> fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
>>>
>>>
>>
>> Definitely. The existing functions should have been named 'joined' and
>> 'splitted'. :o)
>
> I actually hypothesize that "joiner"/"splitter" were chosen because
> "split" the verb's past tense is also "split", which was taken by the
> eager function.

It was intended as a joke, but apparently the word exists/existed https://en.wiktionary.org/wiki/splitted .