OUString is mutable?

[Michael Stahl]

On 01/10/12 11:32, Noel Grandin wrote:
> 
> On 2012-10-01 09:49, David Tardon wrote:
>> I find it perfectly reasonable that a variable of a value type (as 
>> opposed to polymorphic type) is assignable. In fact, I would be 
>> surprised if it were not. Value types are supposed to mimic the
>> behavior of primitive types; that is why copy constructor and
>> operator= are created by the compiler unless one disables them. You
>> are not surprised that
> 
> David, I agree with you - what I'm really getting at here is that it
>  seems perfectly reasonable to me to fold the functionality of 
> OUStringBuffer into OUString, making our string classes that much
> simpler. Otherwise we're going to end up constantly converting
> between the two for no good reason that I can see.

it appears that there are people who do see good reasons for immutable
strings :)

the "D" language, designed as a successor to C++ with more of a system
programming audience in mind than Java, also has immutable std.string:

http://dlang.org/phobos/std_string.html

>>> String handling functions. Objects of types string, wstring, and
>>> dstring are value types and cannot be mutated element-by-element.
>>> For using mutation during building strings, use char[], wchar[],
>>> or dchar[]. The *string types are preferable because they don't
>>> exhibit undesired aliasing, thus making code more robust.

there is also a library that is apparently proposed to become
boost::const_string:

http://conststring.sourceforge.net/

from what i can see the advantages of immutable strings include:

- somebody reading the code can rely on the fact that the buffer in the
  string is not mutated
- immutable data types are much less error prone as hashtable/map keys
  (you don't want to modify a key after it has been inserted, because
  that is practically guaranteed to violate container's invariants)
- the buffer can be shared across threads (but not the string wrapper
  itself, which makes this .. less of an advantage)
- there are potential space and allocation savings with sharing
  sub-string representations (though OUString doesn't do that)
- it allows for caching the hash value, though OUString doesn't do that
  (and i don't know if space overhead is worth it...)

disadvantages:

- conceptual overhead of 2 classes makes code more difficult to write
- have to explicitly convert back and forth when you do want to mutate

i'm personally of the opinion that reading code easily & getting the
right understanding of what it does is more important than writing code,
so i'm a bit in favor of immutable string :)  and i think that the vast
majority of String/OUString instances are not actually mutated after
being constructed, so it's not much effort.

basically immutable string is a value type, like an integer, and a
mutable string is a full-fledged object with an internal state that may
change over time, so even though you do need a mutable companion object
like OUStringBuffer in certain situations i'd even say that despite that
to me immutable strings are conceptually simpler.