xxxInPlace or xxxCopy?

[spir]

On 01/20/2011 12:33 AM, Andrei Alexandrescu wrote:
> I'm consolidating some routines from std.string into std.array. They are
> specialized for operating on arrays, and include the likes of insert,
> remove, replace.
>
> One question is whether operations should be performed in place or on a
> copy. For example:
>
> string s = "Mary has a lil lamb.";
> // Implicit copy
> auto s1 = replace(s, "lil", "li'l");
> assert(s == "Mary has a lil lamb.");
> // Explicit in-place
> replaceInPlace(s, "lil", "li'l");
> assert(s == "Mary has a li'l lamb.");
>
> So that would make copying the default behavior. Alternatively, we could
> make in-place the default behavior and ask for the Copy suffix:
>
> string s = "Mary has a lil lamb.";
> // Explicit copy
> auto s1 = replaceCopy(s, "lil", "li'l");
> assert(s == "Mary has a lil lamb.");
> // Implicit in-place
> replace(s, "lil", "li'l");
> assert(s == "Mary has a li'l lamb.");
>
>
> Thoughts?

I have thought at these issues (there are several playing together) in 
other languages.

The first problem is indeed that both operations may often be useful. If 
you define it to operate in-place, then when the user instead wants a 
new element, they need copy first:
	col2 = col1;
	col2.sort();
If instead you define it to create a new element, then conversely when 
the user wants it to operate in-place, they need to reassign:
	col1 = col.sorted;

The second point is how to hint the user to the actual semantics, and 
avoid possibly naughty bugs. It's mainly a question of naming. I have 
decided to follow once and for all the below guideline:
* In-place modification is an action, thus it's name is an action verb, 
like "sort" (indeed, english is very often ambiguous; in such cases, 
verbal sense take precedence, else add some more word).
* Creating a new is a function in the pure, math, sense of the word (not 
the C sense); name after what it creates. Usually, a simple adjective 
does the job, else add a noun: "sorted", "sortedTable", "sortedList".
* Never mix both action & function in the same routine (except for 
signaling error in language without any exception system).

It is often worth having both operations; difference of naming makes 
this easy to manage. When having both is overkill, I decided to return a 
new element for methods operating globally, and modify in-place for 
methods operating at the level of element(s). The reason is the first 
ones are usually costly, so it's worth using the safer functional scheme 
(and copying sometimes allows faster algo). While creating a whole new 
collection after any minimal change on element(s) is obviously not very 
efficient.

These questions, as taken implicitely in this thread, mostly concern 
collections. Now, the case of string chosen as initial example is as 
always very particular. I'm not fan for this reason of the politics of 
using the same methods as for (other) arrays, except in cases where it's 
obvious. D strings are even more particular by having immutable 
elements. Well...
My 2 cents.

Denis
_________________
vita es estrany
spir.wikidot.com