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. _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
