Hi, Jeff Garland wrote:
There's no restriction on for_each. I think the value of transform versus for_each for this case is marginal at best. As for trim versus trimmed, I'm afraid I don't like trimmed much. It's 'past tense'. To my ear it strikes as odd -- like the operation is already done. I normally think of mutating functions a present tense verbs. Just looking around a bit, Boost.string_algo-trim, QTString-trimmed, Java.String-trim, RWCString-strip -- so it's not that consistent. As much as anything I'm leveraging Boost.string_algo here, so consistent naming is a virtue.
Hopefully this won't make you mad, but your prior email made me realize that the mutating functions should return a self reference so now you can write:
s.trim().to_upper().append(" more stuff ");
The other thing it made me realize is that it would be handy to have additional overloads on the number of parameters in append/insert_at. So in the next version you'll be able to write:
double dbl = 1.12345; int i = 100;
s.append(dbl, " a string ", i); //"1.12345 a string 100"
I'll probably do something like boost.tuple and support up to 10 arbitrary parameters. And at the suggestion of someone else, I'm also adding boost.format into the mix:
s.append_formatted(dbl, "-some string-", i, "%-7.2f %s %=5d"); //"1.12 -some string- 100 "
So I'm afraid I'm making it more mutable, not less ;-)
I was following this discussion closely. I must say that I kind of like your class. Especially in the way you propose it - as a convenience wrapper build on top of algorithms. Having both, we have win-win scenario. Just one remark on top of mutable vs. copy. As you said, the major reason for coming with this class was a clarity of code. I must say, that when I read s.trim(), I pretty much assume, that the operation is performed on 's'. So mutable is natural winner for me here. Regards, Pavol