xxxInPlace or xxxCopy?

[Jonathan M Davis]

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