On Wednesday 19 January 2011 18:36:55 so wrote: > > And honestly, from the standpoint of code simplicity and > > understandability, > > there's a lot to be said for making copies being the default rather than > > mutation. You can then use the InPlace versions if you need the boost in > > efficiency. > > > > - Jonathan M Davis > > Isn't simplicity and understandability favors the in-place style on these > type of algorithms? > As Jesse Phillips said, it is same as sort.
No. I'd argue that it's clearer to see stuff like auto newStr = replace(str, "hello", "world"); auto sorted = sort(newStr); than to see stuff like replace(str, "hello", "world"); sort(newStr); If you have replace(str, "hello", "world"); you don't know whether it's changed the value in place or if you're throwing away a return value. However, if you have auto newStr = replace(str, "hello", "world"); replaceInPlace(newStr, "world", "hello"); it's quite clear that the first one returns a value and the the second one does it in place. Whereas if you have auto newStr = replaceCopy(str, "hello", "world"); replace(newStr, "world", "hello"); the first one is clear, but the second one is only clear because seeing the first one makes it obvious that the second one must be doing something different. And even then, I'd argue that the name replaceCopy is more ambiguous than replaceInPlace. I think that it's far more likely that a function xCopy is going to have possible alternate meanings that xInPlace would, since not only is copy both a verb and a noun, but it can be used in a lot more situations, whereas InPlace is pretty limited and thus clear. Not to mention, if a function says copy, that implies that it might actually be _copying_ rather than slicing, which many xCopy functions would actually be doing rather than actually copying. So, using Copy in the name is actual ambiguous _regardless_ of what the first part of the function name is. In functional languages, it's _required_ that a function return the changed value instead of changing the one passed in. You're far less likely to accidentally mutate stuff if you program that way, even if you're not dealing with immutable or const values. I think that code is much cleaner if you program in a functional style. The problem is, of course, that you can't constantly be copying everything all the time, because there's a definite performance hit for doing that. So, you have functions which make changes in place when you need to do that. So, I'd argue that it's generally better to program using a functional style if you can and then use mutation if necessary for performance. x and xInPlace support that while xCopy and x do not. However, I think that the biggest argument in favor of using x and xInPlace is that strings are by far the most used type of array, and they _need_ to use the version which makes a copy or slices the array. So, if the x / xInPlace naming scheme would result in x being used more than xInPlace, whereas xCopy / x would result in xCopy being used the most. And I really think that the shorter version should be the one which is going to be used the most. Not to mention, that's the way that the string functions have been done thus far, so sticking to x / xInPlace will break less code. - Jonathan M Davis