I'm about to commit a version of DOMString with many of the changes that
have been discussed in this thread, but not all, at least not yet.
Differences from Robert's original list (the message that started this
thread) are these:
o I did not remove the DOMString(char *) constructor. There's
just too much use of it, much of it in code outside of my
control.
I did add the new member function (Robert's suggestion)
static DOMString DOMString::transcode(char *)
which does the same thing but lets you be explicit about it.
And is nicely symmetric with the existing transcode().
o DOMString::DOMString(size_t), for reserving buffer space, is removed.
But an overloaded constructor taking(int) remains, to avoid
breaking java-like code of the form
someDOMString = null;
There is enough usage of this construct that I prefer not to
break it, and, for better or worse, these DOM bindings do try
to be as compatible as reasonably possible with the Java.
Overloading on DOMNullPointer * doesn't work in this case because
it is ambiguous when null is defined to be 0.
The new overload is documented as being for handling nulls only,
and the implementation has an assert check for the passed value
being null. Not as nice as catching problems at compile time,
but better than nothing.
o Erase() isn't in. I think that it should be, but am unsure
of the name. DOMString already has deleteData(), taken from
the CharacterData interface in the W3C DOM spec, along with
appendData(). Maybe a no-parameters overload of this would
be better.
o The XMLStrL is not in. I'd like to see something like it,
but I don't think that I fully understand everything about
this problem yet. I'm also a little worried about having a
function whose efficiency of operation can not be known by
a developer - it could be a compile time constant or an
expensive call to a transcoding service.
The rest is there, including all of the proposed overloads of + and +=,
and a fix to appendData() to make it work efficiently with strings
with reserved buffer space.
-- Andy
