Re: std.uni.toLowerCase / .toUpperCase
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.
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis wrote: When adding lazy versions in the past, for better or worse, we've generally gone for using nouns, whereas you're suggesting adjectives based coming from the past tense of a verb (though the verb to case has nothing with the case of letters). OK, so I didn't really understand what were you referring to, since the only examples I found while looking through the *stable* documentation were joiner and splitter. But I went through the list of new symbols, and I found that a few more have been added after the last release to std.string: en/detabber, left/right/centerJustifier, soundexer So, one option is to stay consistent with these additions, and go with upperCaser and lowerCaser, even if those sound a bit odd. Another option would be to rename those additions as well, so we would have: en/detabbed, left/right/centerJustified, soundexed, upperCased, lowerCased I don't know if this counts as being outside of the scope of this thread. Any thoughts? Or is everyone bored to death already? :)
Re: std.uni.toLowerCase / .toUpperCase
On 24/06/15 22:56, Steven Schveighoffer wrote: I recently started learning ruby. Going through a tutorial, I came across this gem (no pun intended) when talking about how both intern and to_sym do the same thing: Hmm, I didn't know about intern. I've never seen in the wild. Why have multiple ways to do the same things? Well, that's a silly question. To be able to write expressive code. A language that only has one way to get from A to B is not a language at all. Wow. Hehe :) -- /Jacob Carlborg
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 20:03:35 UTC, Vladimir Panteleev wrote: On Wednesday, 24 June 2015 at 13:35:06 UTC, Vladimir Panteleev wrote: The problem with toXCase is that there is neither a noun for an upper-case transform, nor a verb for such an operation, such as e.g. capitalization and capitalize, so I think we should look at it separately. Well, I suppose simply upperCase and lowerCase are an options, if you squint your eyes and pretend they're verbs. Of course, even if you consider these acceptable on their own, they don't really solve the problem of being memorably distinguishable from toLower / toUpper.
Re: std.uni.toLowerCase / .toUpperCase
On 24/06/15 22:07, Suliman wrote: If not to look at docs I would say that size is bite size, count - number of elements. So what is length I can't say. Probably I missed length and count. length and size are the exact same thing. They return the number of elements of an array or string. count is a bit more versatile, it can be called without parameters, with one parameter or with a block. If a parameter is given it will count the number of occurrences of that element. If a block is given it will pass each element to the block and count how many times it returns true. If no parameter or block is given it will work exactly like length and size. It gets event more interesting if you add ActiveRecord to the mix. The result of a query in ActiveRecord will return some form of object that acts like an array. Example: Person.where(name: 'John').length Will get all rows matching John and return how many. This on the other hand: Person.where(name: 'John').count Will actually perform a count query, avoid loading all objects in memory. -- /Jacob Carlborg
Re: std.uni.toLowerCase / .toUpperCase
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.
Re: std.uni.toLowerCase / .toUpperCase
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)
Re: std.uni.toLowerCase / .toUpperCase
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.
Re: std.uni.toLowerCase / .toUpperCase
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 .
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 14:10:45 UTC, 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)) Well, I have to disagree there, particularly when the er version of things is much more indicative of what's actually going on (a series of constructor calls, really - they're just done via wrapper functions). I can get behind the asXxx scheme when the xxxer scheme doesn't fit, but in general, I think that going with the xxxer scheme fits in very well with what's actually going on and will thus actually help make the code clearer, whereas I really don't think that that's the case with xxxed. - Jonathan M Davis
Re: std.uni.toLowerCase / .toUpperCase
On 6/25/15 7:10 AM, 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)) I agree with Jonathan that the latter is clearer as to what the method is doing--constructing something that will do the work. However, I agree that the former reads much better. My bikeshed is painted the former way, mainly because it encourages people to use the range-based style because it reads so well. With that said I'm hopeful that Adam's trick will obviate at least some of this discussion.
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 13:48:41 UTC, Jonathan M Davis wrote: Also, the less that we have to rename the better Well, just to keep in mind, we're going to establish a convention in this release even if we do not explicitly state so - because in future naming decisions, we *will* be using precedent for consistency, as we're using now. So, I'm not saying we *should* go back and rename almost everything added in 2.068 now, but I'm saying that we shouldn't allow these hastily-chosen initial names to be a factor in deciding how to name things from now on. I certainly wouldn't mind renaming all of them. And, IMHO, this: fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(.foo)) looks much better than this: fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(.foo))
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 13:48:41 UTC, Jonathan M Davis wrote: I prefer the noun naming scheme to the adjective naming scheme. We really haven't been using adjectives much, and I think that nouns make more sense, since what you're basically doing is constructing an object. So, I'd just as soon not start using adjectives for functions which return lazy ranges. What do you think of asLowerCase? I heard no objections, this one actually sounds like proper English, and it's consistent with the only better name for toAbsolutePath that I could think of (asAbsolutePath). Also, the less that we have to rename the better, so if many of the newer functions are already nouns, then it makes sense to continue that (and it wouldn't surprise me if some of the newer ones were in 2.067, in which case, it's likely too late to change them unless they're particularly bad). No, I'm looking at the diff of functions between 2.067 and master, and the only verb-noun names in 2.067 are joiner and splitter.
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev wrote: On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis wrote: When adding lazy versions in the past, for better or worse, we've generally gone for using nouns, whereas you're suggesting adjectives based coming from the past tense of a verb (though the verb to case has nothing with the case of letters). OK, so I didn't really understand what were you referring to, since the only examples I found while looking through the *stable* documentation were joiner and splitter. But I went through the list of new symbols, and I found that a few more have been added after the last release to std.string: en/detabber, left/right/centerJustifier, soundexer So, one option is to stay consistent with these additions, and go with upperCaser and lowerCaser, even if those sound a bit odd. Another option would be to rename those additions as well, so we would have: en/detabbed, left/right/centerJustified, soundexed, upperCased, lowerCased I don't know if this counts as being outside of the scope of this thread. Any thoughts? Or is everyone bored to death already? :) I prefer the noun naming scheme to the adjective naming scheme. We really haven't been using adjectives much, and I think that nouns make more sense, since what you're basically doing is constructing an object. So, I'd just as soon not start using adjectives for functions which return lazy ranges. Also, the less that we have to rename the better, so if many of the newer functions are already nouns, then it makes sense to continue that (and it wouldn't surprise me if some of the newer ones were in 2.067, in which case, it's likely too late to change them unless they're particularly bad). - Jonathan M Davis
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis wrote: So, if we're going to be more consistent, I think that following what we've done with splitter makes more sense, and while that's ugly in this case, what you're suggestion is just as ugly. And I think that I'd rather see the annoyance of having toLower/toUpper and toUpperCase and toLowerCase in the same module than start naming functions after adjectives - especially when the resulting name is ugly like it is here. - Jonathan M Davis If nouns are the convention we want, then one option might be to just introduce one function capitalizer and have the case type be an additional argument to the function, aka: capitalizer!lower/ capitalizer!upper/ capitalizer!title. Or lowerCapitalizer/ upperCapitalizer might work as well. setExtension would then obviously translate to extensionSetter. Though adams idea also seems very good but with the drawback of some broken code.
Re: std.uni.toLowerCase / .toUpperCase
On Tue, 23 Jun 2015 22:58:30 +, Vladimir Panteleev wrote: Proposed new name: lowerCased / upperCased +1 to this or https://github.com/D-Programming-Language/phobos/pull/3243
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 00:16:49 UTC, Tofu Ninja wrote: But now you are going to have to come up with a clever name for every replacement and the clarity of each will be shoty at best. The append lazy convention at least is a convention that is very clear, the other way has no rules, you just are making up new names. A UFCS chain of functions full of the word 'lazy' is going to look pretty clunky. auto gubbins = guns.setStuffLazy.doMoreThingsLazy.turnOnLasersLazy.fireLasersLazy.coolLasersLazy; Would using the same names be a possibility for lazy and eager functions? At least going forward. Default to lazy and instantiate as eager otherwise. Is it possible to make a meta template that would instantiate all functions in a chain as lazy or eager as desired? setExt!eager and setExt
Re: std.uni.toLowerCase / .toUpperCase
On 6/24/15 3:59 PM, Jacob Carlborg wrote: On 24/06/15 15:43, Adam D. Ruppe wrote: Absolutely. I don't even like names that are just kinda similar. Ruby, for example, has `chop` and `chomp`. What's the difference? idk, I have to look it up. (chop will also remove non-newlines from the end) Yeah, Ruby has one too many aliases: filter/select, find/detect, map/collect and the best: size/length/count. Do you know the difference between size, length and count? I recently started learning ruby. Going through a tutorial, I came across this gem (no pun intended) when talking about how both intern and to_sym do the same thing: Why have multiple ways to do the same things? Well, that's a silly question. To be able to write expressive code. A language that only has one way to get from A to B is not a language at all. Wow. -Steve http://www.codecademy.com/forum_questions/512a675cf116c52d0d00674b
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 20:03:35 UTC, Vladimir Panteleev wrote: Well, I suppose simply upperCase and lowerCase are an options, if you squint your eyes and pretend they're verbs. The opposite of lowerCase would be raiseCase. ;) (Huh, transposeCase?) -Wyatt
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 13:35:06 UTC, Vladimir Panteleev wrote: I think someone suggested lowerCased and upperCased somewhere, I think there are fine too. There is some precedent (transposed and indexed). Err, that someone was me. I thought my initial suggestion was asLowerCase / asUpperCase.
Re: std.uni.toLowerCase / .toUpperCase
On 24/06/15 03:05, Vladimir Panteleev wrote: Well, it's true, any chosen decision is going to be a compromise. Appending Lazy is only easy because the work to come up with suitable names has already been done for the eager variants. Finding suitable names for the lazy variants would entail doing similar work, perhaps with a bit more effort to communicate that this version is not eager. It's hard enough to come up with one good name, it will be even harder to come up with a second name. Trying to come up with names indicating one is eager and one is lazy will be almost impossible. I'll collect some data tomorrow to see if it's possible to find a likeable convention for lazy function names. But even if this will fail and we'll have to settle for inconsistency, I think overall the situation will still be better than having Lazy sprinkled everywhere. It will also be consistent with the names so far (e.g. join/joiner) :) join/joiner is almost as bad as setExtension/setExt. -- /Jacob Carlborg
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis wrote: If we want to be consistent with the likes of splitter, then they should be something more like lowerCaser and upperCaser (though caser isn't really word, and AFAIK, there is no noun for something which changes the case of a letter). When adding lazy versions in the past, for better or worse, we've generally gone for using nouns, whereas you're suggesting adjectives based coming from the past tense of a verb (though the verb to case has nothing with the case of letters). I think splitter and joiner are the exception rather than the rule, actually: http://wiki.dlang.org/Naming_conventions Most of the hypothetical names in that column (verb-noun) are pretty ugly. I don't think this is a convention we should adopt. The problem with toXCase is that there is neither a noun for an upper-case transform, nor a verb for such an operation, such as e.g. capitalization and capitalize, so I think we should look at it separately. I think someone suggested lowerCased and upperCased somewhere, I think there are fine too. There is some precedent (transposed and indexed).
Re: std.uni.toLowerCase / .toUpperCase
On 24/06/15 07:20, Jonathan M Davis wrote: If we want to be consistent with the likes of splitter, then they should be something more like lowerCaser and upperCaser (though caser isn't really word, and AFAIK, there is no noun for something which changes the case of a letter). How is that consistent? The original names are toLower/toUpper, not lowerCase/upperCase. So it should be something like toLowerer but that clearly doesn't work. -- /Jacob Carlborg
Re: std.uni.toLowerCase / .toUpperCase
On 24/06/15 09:03, Tofu Ninja wrote: If nouns are the convention we want, then one option might be to just introduce one function capitalizer and have the case type be an additional argument to the function, aka: capitalizer!lower/ capitalizer!upper/ capitalizer!title. Or lowerCapitalizer/ upperCapitalizer might work as well. I don't like that. There's a method in Ruby on Rails that's called capitalize. It converts the first letter to a capital and the remaining ones to lower case. -- /Jacob Carlborg
Re: std.uni.toLowerCase / .toUpperCase
On 24/06/15 01:17, Meta wrote: I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too clever and really just ends up causing unnecessary confusion. This is not Ruby. [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx +1 -- /Jacob Carlborg
Re: std.uni.toLowerCase / .toUpperCase
On 24/06/15 02:17, Mike wrote: Ok, I'm with you. Allow me to offer another suggestion then. 1. Add functions `toUpperCaseEager` and `toLowerCaseEager`. 2. Have `toUpper` forward to `toUpperCaseEager` and `toLower` forward to `toLowerCaseEager` with a friendly comment. You don't need to deprecate `toUpper` or `toLower` unless you want to. It will happen naturally and gradually in time anyway. 3. Add functions `toUpperCase` and `toLowerCase` implementing the lazy versions. How will that make things better? A user will see both toLower and toLowerCase can think: What the h*ll is the difference between these to functions. -- /Jacob Carlborg
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 13:43:50 UTC, Adam D. Ruppe wrote: Yes, just provide a function that works on chars and reuse map for laziness. Actually, this might not quite work because toLower/Upper might need to transform two characters at once in some alphabets. Ugh. still I do generally like the idea of getting users used to composing building blocks themselves. We provide the pieces and the docs tell them how to put it together. If foo().bar() works, no need to always write a new foobar() function too.
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 13:37:35 UTC, Jacob Carlborg wrote: On 24/06/15 07:20, Jonathan M Davis wrote: If we want to be consistent with the likes of splitter, then they should be something more like lowerCaser and upperCaser (though caser isn't really word, and AFAIK, there is no noun for something which changes the case of a letter). How is that consistent? The original names are toLower/toUpper, not lowerCase/upperCase. So it should be something like toLowerer but that clearly doesn't work. It's consistent with the naming scheme used by functions like splitter, joiner, or filter (though in filter's case, it's both a verb and a noun). The function is named after the noun that does the operation rather than the operation - e.g. the verb is split, but the one that does the splitting is the splitter. So, in the case of toLower and toUpper, what you're manipulating is the case, so following that naming scheme, a lower caser would be what did the to lower case operation, and an upper caser would be what did the to upper case operation. Now, that's ugly since caser isn't a real word (there really isn't a noun for something which changes a letter to uppercase or lowercase), but it's following the same scheme as splitter. Conversely, we could go with lowerer and upperer, though those are pretty ugly and nonsensical too, but having to in the name doesn't follow the convention that we use with functions like splitter or joiner, so toLowerer like you suggest wouldn't fit. All in all, because there is no noun or object which changes the case of letters (it's really just an operation), following the naming scheme of functions like splitter is bound to be ugly. But it _is_ making them consistent with what we've done with the names of existing functions when we've made lazy versions of them (e.g. split - splitter, and join - joiner). - Jonathan M Davis
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 13:31:00 UTC, Jacob Carlborg wrote: How will that make things better? A user will see both toLower and toLowerCase can think: What the h*ll is the difference between these to functions. Absolutely. I don't even like names that are just kinda similar. Ruby, for example, has `chop` and `chomp`. What's the difference? idk, I have to look it up. (chop will also remove non-newlines from the end) At least toLower vs toLowerCase would have different types, so the compiler can help explain which is which, but really, ugh. BTW here's another outside-the-box idea. eager = toLower lazy = map!lowercase Yes, just provide a function that works on chars and reuse map for laziness.
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 03:15:58 UTC, Andrew Gough wrote: On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: A rename can be proposed by creating a subthread: [...] Rationale: As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word Case is omitted. The distinction is not memorable. Proposed new name: lowerCased / upperCased I love painting bike sheds! An eager version implies present tense: split, join etc A lazy version implies future tense: willSplit, willJoin, etc And hence: willUpperCase, willLowerCase
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: A rename can be proposed by creating a subthread: [...] Rationale: As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word Case is omitted. The distinction is not memorable. Proposed new name: lowerCased / upperCased I love painting bike sheds! An eager version implies present tense: split, join etc A lazy version implies future tense: willSplit, willJoin, etc
Re: std.uni.toLowerCase / .toUpperCase
On 24/06/15 15:43, Adam D. Ruppe wrote: Absolutely. I don't even like names that are just kinda similar. Ruby, for example, has `chop` and `chomp`. What's the difference? idk, I have to look it up. (chop will also remove non-newlines from the end) Yeah, Ruby has one too many aliases: filter/select, find/detect, map/collect and the best: size/length/count. Do you know the difference between size, length and count? -- /Jacob Carlborg
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 13:35:06 UTC, Vladimir Panteleev wrote: The problem with toXCase is that there is neither a noun for an upper-case transform, nor a verb for such an operation, such as e.g. capitalization and capitalize, so I think we should look at it separately. Well, I suppose simply upperCase and lowerCase are an options, if you squint your eyes and pretend they're verbs.
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 20:00:00 UTC, Jacob Carlborg wrote: On 24/06/15 15:43, Adam D. Ruppe wrote: Absolutely. I don't even like names that are just kinda similar. Ruby, for example, has `chop` and `chomp`. What's the difference? idk, I have to look it up. (chop will also remove non-newlines from the end) Yeah, Ruby has one too many aliases: filter/select, find/detect, map/collect and the best: size/length/count. Do you know the difference between size, length and count? Adam, +1, I am always confusing when try to remember difference between chomp and chop. If not to look at docs I would say that size is bite size, count - number of elements. So what is length I can't say. Probably I missed length and count.
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: A rename can be proposed by creating a subthread: [...] Rationale: As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word Case is omitted. The distinction is not memorable. Proposed new name: lowerCased / upperCased Havent't read the entire thread yet, but in case it hasn't been suggested yet: inLowerCase / inUpperCase
Re: std.uni.toLowerCase / .toUpperCase
On 6/23/2015 4:49 PM, Vladimir Panteleev wrote: IMHO, in this case, the Lazy suffix is a distracting technicality that doesn't carry its weight. Am I the only one? Nope. For the reasons you mentioned.
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: A rename can be proposed by creating a subthread: [...] Rationale: As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word Case is omitted. The distinction is not memorable. Proposed new name: lowerCased / upperCased If we want to be consistent with the likes of splitter, then they should be something more like lowerCaser and upperCaser (though caser isn't really word, and AFAIK, there is no noun for something which changes the case of a letter). When adding lazy versions in the past, for better or worse, we've generally gone for using nouns, whereas you're suggesting adjectives based coming from the past tense of a verb (though the verb to case has nothing with the case of letters). I'm not really a fan of having both toLower/toUpper and toLowerCase/toUpperCase - especially when the longer version is the lazy one - but lowerCased and upperCased are both ugly and don't follow any kind of convention that we've been using and don't follow a convention that I think we should use. Much as functions are normally verbs, it makes far more sense to me to have a function named after a noun than an adjective if it's returning a lazy range, since then you're essentially naming the function after the range (like a constructor). So, if we're going to be more consistent, I think that following what we've done with splitter makes more sense, and while that's ugly in this case, what you're suggestion is just as ugly. And I think that I'd rather see the annoyance of having toLower/toUpper and toUpperCase and toLowerCase in the same module than start naming functions after adjectives - especially when the resulting name is ugly like it is here. - Jonathan M Davis
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 03:29:28 UTC, Walter Bright wrote: On 6/23/2015 4:49 PM, Vladimir Panteleev wrote: IMHO, in this case, the Lazy suffix is a distracting technicality that doesn't carry its weight. Am I the only one? Nope. For the reasons you mentioned. Agreed. It would be horrible to be putting Lazy on the end of all of the lazy stuff. If we were doing all of the names from scratch then maybe it would make sense to slap Eager on the end of the eager ones on the theory that the lazy ones should be preferred, but even that's pretty ugly. However, if we were doing it from scratch, we probably wouldn't even _have_ most of the eager functions. Regardless, let's not add Lazy to any of these function names. - Jonathan M Davis
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote: I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too clever and really just ends up causing unnecessary confusion. This is not Ruby. [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx I'm not sure about this... I've seen another proposal for a lazy suffix in the other thread, but I think this won't be great in the long run: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. - There is no consistency with any existing naming schemes. Currently no names in Phobos contain the word Lazy. And hopefully not many would have to. I can't say that this is the right solution for all lazy / range-based code going forward, but it's better than what we have, and I believe it's better than withExtension / upperCased / etc. - If std.algorithm were to follow this convention, it would have lazyJoin instead of joiner, lazySplit instead of splitter, lazyConcat OSLT instead of chain, etc. Given a typical program using std.algorithm, do you think such names would look better there than the current ones? They would definitely be more recognizable as lazy functions, at the least. This would make code using std.algorithm more verbose, but we're not looking at changing every name in std.algorithm. We're looking at changing a couple of very bad names that give no indication that they're lazy / range-based (and let's not forget that the two aren't synonymous; we do have a lazy keyword after all). - I'm not sure about the C# async analogy: with async, the methods are used in a different way. The new range-based functions are used in the same way, but work on different types. Here's an example program using setExt[ension] and toLower[Case], in 4 variants... https://gist.github.com/CyberShadow/5cc7e926f566d56a672f IMHO, in this case, the Lazy suffix is a distracting technicality that doesn't carry its weight. Am I the only one? It is a bit longer, but 4 extra characters is not all that much to pay to make a few functions much clearer about what they do.
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: A rename can be proposed by creating a subthread: [...] Rationale: As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word Case is omitted. The distinction is not memorable. Proposed new name: lowerCased / upperCased I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too clever and really just ends up causing unnecessary confusion. This is not Ruby. [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx
Re: std.uni.toLowerCase / .toUpperCase
On Tue, Jun 23, 2015 at 4:27 PM, Tofu Ninja via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote: On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote: Proposed new name: lowerCased / upperCased I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). ... Yes please! If I didn't know what they were replacing, I would have no idea what withExtension, lowerCased, or upperCased meant at all. They hardly seem better than what they are replacing. Just do setExtensionLazy / toLowerLazy / toUpperLazy. It is much simpler and clearer. Counter argument: If the lazy versions are expected to be preferred/used often, then using a 'Lazy' suffix for them is wordy and counterproductive. You want the preferred method to be nicer than the alternative, which having extra 'Lazy' on the end isn't. Lazy suffix smacks of lazy naming to me. Point the first: There should be a different convention for these different methods (believe there is no argument here). Point the second: This convention should apply throughout phobos, trying to choose on a method-by-method basis gives a crappy library. Point the third: Pretty/intuitive range-centric names are good. Names should reflect that this is a different approach, not just 'toFooRanged'. TL;DR I like Vladimir's names, don't like toLowerLazy.
Re: std.uni.toLowerCase / .toUpperCase
On Tue, Jun 23, 2015 at 4:49 PM, Vladimir Panteleev via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote: I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too clever and really just ends up causing unnecessary confusion. This is not Ruby. [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx I'm not sure about this... I've seen another proposal for a lazy suffix in the other thread, but I think this won't be great in the long run: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. - There is no consistency with any existing naming schemes. Currently no names in Phobos contain the word Lazy. - If std.algorithm were to follow this convention, it would have lazyJoin instead of joiner, lazySplit instead of splitter, lazyConcat OSLT instead of chain, etc. Given a typical program using std.algorithm, do you think such names would look better there than the current ones? - I'm not sure about the C# async analogy: with async, the methods are used in a different way. The new range-based functions are used in the same way, but work on different types. Here's an example program using setExt[ension] and toLower[Case], in 4 variants... https://gist.github.com/CyberShadow/5cc7e926f566d56a672f IMHO, in this case, the Lazy suffix is a distracting technicality that doesn't carry its weight. Am I the only one? +1 If I'd seen this two minutes ago could have saved me some typing.
Re: std.uni.toLowerCase / .toUpperCase
On Wednesday, 24 June 2015 at 00:16:49 UTC, Tofu Ninja wrote: On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev wrote: Another point: the range-ification of Phobos is only going to continue. This means that, should this scheme be followed, the number of functions with Lazy in the same is only going to grow, and as these functions are intended to become the canonical way to write modern D, so will the number of occurrences of Lazy in a typical canonical D program. I think this is a strong argument for avoiding Lazy, at least for functions which intend to displace their eager counterparts. But now you are going to have to come up with a clever name for every replacement and the clarity of each will be shoty at best. The append lazy convention at least is a convention that is very clear, the other way has no rules, you just are making up new names. Well, it's true, any chosen decision is going to be a compromise. Appending Lazy is only easy because the work to come up with suitable names has already been done for the eager variants. Finding suitable names for the lazy variants would entail doing similar work, perhaps with a bit more effort to communicate that this version is not eager. I'll collect some data tomorrow to see if it's possible to find a likeable convention for lazy function names. But even if this will fail and we'll have to settle for inconsistency, I think overall the situation will still be better than having Lazy sprinkled everywhere. It will also be consistent with the names so far (e.g. join/joiner) :)
std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: A rename can be proposed by creating a subthread: [...] Rationale: As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word Case is omitted. The distinction is not memorable. Proposed new name: lowerCased / upperCased
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote: I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too clever and really just ends up causing unnecessary confusion. This is not Ruby. [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx I'm not sure about this... I've seen another proposal for a lazy suffix in the other thread, but I think this won't be great in the long run: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. - There is no consistency with any existing naming schemes. Currently no names in Phobos contain the word Lazy. - If std.algorithm were to follow this convention, it would have lazyJoin instead of joiner, lazySplit instead of splitter, lazyConcat OSLT instead of chain, etc. Given a typical program using std.algorithm, do you think such names would look better there than the current ones? - I'm not sure about the C# async analogy: with async, the methods are used in a different way. The new range-based functions are used in the same way, but work on different types. Here's an example program using setExt[ension] and toLower[Case], in 4 variants... https://gist.github.com/CyberShadow/5cc7e926f566d56a672f IMHO, in this case, the Lazy suffix is a distracting technicality that doesn't carry its weight. Am I the only one?
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev wrote: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. Another point: the range-ification of Phobos is only going to continue. This means that, should this scheme be followed, the number of functions with Lazy in the same is only going to grow, and as these functions are intended to become the canonical way to write modern D, so will the number of occurrences of Lazy in a typical canonical D program. I think this is a strong argument for avoiding Lazy, at least for functions which intend to displace their eager counterparts.
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev wrote: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. Another point: the range-ification of Phobos is only going to continue. This means that, should this scheme be followed, the number of functions with Lazy in the same is only going to grow, and as these functions are intended to become the canonical way to write modern D, so will the number of occurrences of Lazy in a typical canonical D program. I think this is a strong argument for avoiding Lazy, at least for functions which intend to displace their eager counterparts. Ok, I'm with you. Allow me to offer another suggestion then. 1. Add functions `toUpperCaseEager` and `toLowerCaseEager`. 2. Have `toUpper` forward to `toUpperCaseEager` and `toLower` forward to `toLowerCaseEager` with a friendly comment. You don't need to deprecate `toUpper` or `toLower` unless you want to. It will happen naturally and gradually in time anyway. 3. Add functions `toUpperCase` and `toLowerCase` implementing the lazy versions. Something similar could also be applied to `setExtension` 1. Add `setExt` implementing the lazy version and `setExtEager` implementing the eager version 2. Forward `setExtension` to `setExtEager` with a friendly comment. Again, you don't need to deprecate `setExtension` unless you want to. It will happen naturally and gradually in time anyway. If this only makes things worse in your opinion, go with `withExtension` and your other suggestions. I'm already weary of this. Mike
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev wrote: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. Another point: the range-ification of Phobos is only going to continue. This means that, should this scheme be followed, the number of functions with Lazy in the same is only going to grow, and as these functions are intended to become the canonical way to write modern D, so will the number of occurrences of Lazy in a typical canonical D program. I think this is a strong argument for avoiding Lazy, at least for functions which intend to displace their eager counterparts. But now you are going to have to come up with a clever name for every replacement and the clarity of each will be shoty at best. The append lazy convention at least is a convention that is very clear, the other way has no rules, you just are making up new names.
Re: std.uni.toLowerCase / .toUpperCase
`toLowerLazy`/`toUpperLazy` Rationale * sorts well with `toUpper/Lower` for tooling * implies that it is related to `setUpper/Lower` in some way * at-a-glance disambiguates it from `toUpper/Lower` with a clue as to how it is differrent Mike
Re: std.uni.toLowerCase / .toUpperCase
On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote: On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: A rename can be proposed by creating a subthread: [...] Rationale: As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word Case is omitted. The distinction is not memorable. Proposed new name: lowerCased / upperCased I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too clever and really just ends up causing unnecessary confusion. This is not Ruby. [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx Yes please! If I didn't know what they were replacing, I would have no idea what withExtension, lowerCased, or upperCased meant at all. They hardly seem better than what they are replacing. Just do setExtensionLazy / toLowerLazy / toUpperLazy. It is much simpler and clearer.
