Re: OUString's buffer is not mutable (was: Re: OUString is mutable?)

On Friday 05 of October 2012, Michael Stahl wrote:
> On 04/10/12 15:29, Lubos Lunak wrote:
> > On Wednesday 03 of October 2012, Michael Stahl wrote:

> hmm i am not really familiar with "D" and just believed the first
> sentence on its string documentation page :)
>
> so let's read more of it...

 Let's not. What D or any other random language does is not necessarily 
relevant here.

> >  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?
> >
> >     OUString & operator+=( const OUString & str ) SAL_THROW(())
> >     {
> >         rtl_uString_newConcat( &pData, pData, str.pData );
> >         return *this;
> >     }
>
> it allocates a new string buffer, and does not mutate the OUString's
> exising buffer.

 Exactly. So does that with your interpretation mean that this makes OUString 
mutable or immutable? And all the followup questions.

> >  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.
>
> it seems you are missing the distinction between changing which buffer
> the OUString points to, and mutating elements of the buffer that an
> existing OUString points to, which are separate concerns, as has already
> been discussed in this thread:

 No, I'm perfectly aware of the distiction, just like I'm aware of the fact 
that it's irrelevant to the original question, which is what you seem to be 
missing.

 Noel asked why it is not possible to mutate OUString in-place (just like it's 
possible e.g. with std::string::insert() ). But it is possible to mutate 
OUString in place, as shown by OUString::operator+= . In this view it doesn't 
matter how it's implemented internally. There can be OUString::insert() , 
working rather similarly to OUString::operator+=. It may internally detach 
from a shared implementation detail and modify a copy of it, but that doesn't 
conceptually matter, because OUString::operator+= and all the hypothetical 
similarly working modifying methods like OUString::insert() make OUString 
mutable from the usage point of view, because they modify what the developer 
using it perceives as the string.

 And if you still disagree with this, then you really need to explain what you 
actually mean with 'immutable OUString'. And if you see a good reason why 
e.g. OUString::insert() could not be added, feel free to throw that in too (I 
don't count "Java/D don't do that" alone as a good reason without further 
elaborating).

-- 
 Lubos Lunak
 l.lunak@suse.cz