Re: std.path.setExt
On Tue, 23 Jun 2015 22:51:06 +, Vladimir Panteleev wrote: Proposed new name: withExtension +1
Re: std.path.setExt
On Wednesday, 24 June 2015 at 20:19:49 UTC, Marc Schütz wrote: On Wednesday, 24 June 2015 at 14:01:32 UTC, Wyatt wrote: I don't think I'd interpret these two names as having the same functionality in the first place. I'd probably learn their equivalence completely by accident and only remember it by rote. Interesting. But once you know that, it's easy to tell which is which, no? Is it, though? I mean I _guess_ setExtension() sounds more eager? Familiarity removes my ability to make a first-time judgement. But by the time I've learned of their equivalence and that one is lazy and the other is not, the API has already lost as far as I'm concerned. Maybe this can be mitigated with really good docs that lists paired functions together so it's at least easy to find them. Or here's a thought: Since we apparently want to minimise/kill eagerness, can we detect usage of eager functions and catch/flag them? Similar in ideal to Adam's (brilliant) wrapper thing, but with tooling. A @lazy attribute (analogous to @nogc), or a switch, or dfix rules, or something. I don't know. -Wyatt
Re: std.path.setExt
On Tuesday, 23 June 2015 at 22:51:08 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: Proposed new name: withExtension I feel this fails the litmus you established before: These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which? I don't think I'd interpret these two names as having the same functionality in the first place. I'd probably learn their equivalence completely by accident and only remember it by rote. -Wyatt
Re: std.path.setExt
On Wednesday, 24 June 2015 at 14:01:32 UTC, Wyatt wrote: On Tuesday, 23 June 2015 at 22:51:08 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: Proposed new name: withExtension I feel this fails the litmus you established before: These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which? I don't think I'd interpret these two names as having the same functionality in the first place. I'd probably learn their equivalence completely by accident and only remember it by rote. Interesting. But once you know that, it's easy to tell which is which, no?
Re: std.path.setExt
On Tuesday, 23 June 2015 at 22:51:08 UTC, Vladimir Panteleev wrote: Proposed new name: withExtension I'm fine with withExtension. Certainly, I don't think that anything starting with set really makes sense given that it's a lazy operation. - Jonathan M Davis
Re: std.path.setExt
On Tuesday, 23 June 2015 at 23:13:11 UTC, Mike wrote: `setExtensionLazy` Mike I really don't like the Lazy suffix. Ignoring the issue of making things somewhat uglier solely for the purpose of ambiguity, it also leads to confusion regarding whether you should be invoking foo or fooLazy. Is there a fooLazy for this, or is it just foo, and why? Just because it was implemented before some arbitrary point? The lazy approach should be strongly preferred and should be the default; if the user wants the non-lazy version, they can use .array. Plus, as mentioned, people will start thinking that their own code should use this Lazy suffix which is likely something we don't want to encourage. The current setExt name has the same issues I mentioned above, and it honestly is very odd to me to see setExt as well as setExtension if we're not intending to slowly phase out setExtension. The proposed withExtension indicates that it takes in a range and returns a range with the modifications applied, and I quite like it. I think that should be a trend for lazy algorithms, or at least a way to disambiguate.
std.path.setExt
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: A rename can be proposed by creating a subthread: reply to this post, but change the name to the fully-qualified name of the identifier you'd like to see renamed. Please include a rationale and a proposed new name in your post. I'll start. Rationale: std.path.setExt is the lazy (range-based) version of std.path.setExtension, thus the only difference in the name is that one is abbreviated, and the other is not. As there is no consistent convention that abbreviated names are lazy, it is not memorable which function is which. I presented a case in my earlier thread (point 6): http://forum.dlang.org/post/pnzrkgxkxprsgppxk...@forum.dlang.org Proposed new name: withExtension
Re: std.path.setExt
`setExtensionLazy` Rationale * sorts well with `setExtension` for tooling * implies that it is related to `setExtension` in some way * at-a-glance disambiguates it from `setExtension` with a clue as to how it is differrent The disadvantage is that its a little long, but that's due to the length of Extension not the Lazy suffix. If it's a problem simply create `setExt` and `setExtLazy` and have `setExtension` forward to `setExt`for backward compatibility with a friendly comment. It wouldn't even need to be deprecated. Mike
