> > The LString in the InsetChunk is private!
>
> Then, as I suspected from the beginig, all the set of methods from LString
> won't be used.
They will not be exposed in the Inset base class. However, they will be used!
Since LString is the document representation string, there will be many
routines that work on it. The LString is simply the string that contains the
text in our document, not only in the data structure that holds the text (i.e.
the InsetChunks), but also in all other routines that deal with text: When we
need to convert from encodings, we use the LString as the interface. When we
need to execute lyxfuncs that insert text, we pass an LString. When we need to
search and replace text, we can take advantage of the support in the LString.
Etc, etc.
So, IMO, the methods from LString are all very useful.
Yes, vector and the algorithms in the STL can do the same.
But as previously argued: Vector is inferior to string in three ways:
* The c_str method is constant time in string, linear time in vector.
* Copy is always linear time for vector, while we often have constant time for
string (copy-on-write semantics).
* The string is a well known construction, and using a vector for this instead
is mudding the semantics without any real reason.
Reducing the discussion to a question about whether or not we need this
functionality for InsetChunk is problematic. Obviously the InsetChunk in
itself will not *require* this functionality, but this is not the only place we
use LStrings!
Personally, I feel that we should use exactly one container class for the text,
and use the same in both the InsetChunk representation, and in all the other
places where we need to interface with the text. I feel that it's a problem
with the current data structure, where we use a char array for what corresponds
to our InsetChunk. Other places we use an LString, others it's still a char *,
and this is a mess.
I would much prefer to use the LString all over.
In particular, I strongly oppose against using a C array as data-structure. We
need a class that is assignable in the STL sense.
I feel that the C++ standard string serves our needs well. The only real gribe
that you have mentioned is the complexity of the thing. (The memory
consumption argument is weak, IMO. The main memory consumption in LyX is not
the raw text, but the auxilliary data structures.) Yes, the interface contains
a lot of methods, but so what? Lots of other interfaces has a lot of
functionality as well, but that does not stop us from using them.
We have even implemented our own standard string replacement, and it's an
excellent implementation. Why should we dump that and replace it with
something inferior?
I think that we should use the same container for all documentation strings in
LyX. Having the LString dedicated for this purpose clears the semantics
immensely, and I would prefer to make LString a global phenonomem in all
contexts that deal with text from a document.
I think our own LString is good enough to be the default string, but having a
less usable string would be an error, IMO.
Greets,
Asger
