On Wednesday 03 of October 2012, Michael Stahl wrote: > On 03/10/12 18:19, Lubos Lunak wrote: > > As such, as far as I can tell, immutable OUString is only a complication > > with no practical advantages. > > please read my other mail for other benefits...
I assume you mean the mail where you refer to std.string from the D language and call it immutable because "cannot be mutated element-by-element", even though there is e.g. std.string.toUpperInPlace() , which clearly makes it mutable as far as I understand the definition of mutable. So we apparently do not agree on what immutable actually means after all. There already is OUString::operator+=, so what exactly is your definition of mutable if you think OUString is mutable despite this (and, moreover, why does that definition matter)? And if you think that OUString is immutable and the operator+= is some kind of mistake that should not be there, then what is the difference between operator= and operator+= given that, as far as the outside world is concerned, they do almost the same, except for operator+= modifying its own internal copy of _rtl_uString that's not accessible from outside at the time? I do not see any problem with OUString::operator+= that OUString::operator= would not already have. And since the consensus seems to be that operator= is needed (and indeed OUString would be awfully cumbersome without it), then operator+= can be there as well. And, by extension, a number of other modifying functions. -- Lubos Lunak [email protected] _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
