Re: [boost] string algorithms review (copy vs. mutable)

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-20 08:54:32

I would like to sumariza the current discussion regarding
the copy vs. mutable namining in the string_algo library.

This discussion starts to be typical example of bicycle shed problem,
and I think it is time to come to conclusion.

So far there has been following proposals:

1. Leave it as it is. Copy variants has suffix _copy, mutable none.

2. Change the naming so that copy variants are default, and mutable variants have suffix _inplace

3. Use some kind of proxy object "in_place" which would change the behaviour of an
   algorithm from copy to mutable semantics

4. Various other syntaxes like:

         mutate(s) % trim(3,12), blah(whatever), foo(bar)
    mutate(s) = trim(3,12), blah(whatever), foo(bar)
    s ^= trim(3,12), blah(whatever), foo(bar)
    s = trim(3,12), blah(whatever), foo(bar)

5. Declare common class for all algorithms a.k.a enhanced std::string

In my personal opinion, only first two points are acceptable. Other variants bring only
confusion and complexity to a very simple problem. Why to make thinks complicated, when
there is a simple solution?

Now to show in detail what are pros and cons of the 1. and 2. approach

1.

+/-	Inplace variant is default
-		Does not explicitly identify that the algorithms is mutating
+		Favors more effective inplace variants
+		Being the inplace a better variant for common task, this approach simpyfies the usage.

2.	

+/-  Copy variant is defaul
+	  Does explicitly identify that the algorithm is mutating
-	  Favors slower, less effective variants
-	  More verbose, under assumption, that mutating version is commonly used.

Now the decision has to be taken, what is better solution. 

IMHO it is number 1. My personal preference follows this reasoning:

- C++ is not a functional language, therefore, algorithms tend to have side effects.
- C++ primary goal is efficiency, not the safety for a user (That is a Java domain).
- Most of algorithms in the string_algo library are mutating by nature.
- With the basic knowledge of the lib, it is perfectly clear what do the names denote.
  There are no unexpected exceptions in the string_algo library.
- If it is clear, that there are always two variants, and the copying one si denoted with suffix,
  than it should also be clear, that the variant without suffix if mutating.

These are my arguments, please take them in the consideration. I will not argue any more.
I'm willing to change the interface to type 2 if a common concensus will be taken, that it is better.

Regards,

Pavol