Yes, that would be the simple and idiomatic C++ way to do things. But
DOMString (and some other DOM handle classes) have the ability to mimic
Java's object handle semantics. So, there are empty DOMStrings and there
are "null" DOMStrings and this is not always the same thing.
Here's an example of the subtlety:
DOMString foo;
if (foo.length() == 0) { } // true
if (foo == null) {} // true
foo.appendData("bar");
if (foo.length() == 0) { } // false
if (foo == null) {} // false
// so far so good
foo.deleteData(0,3); // delete the contents of the string. erase() would
have done the same thing
if (foo.length() == 0) { } // true
if (foo == null) {} // false, we have a non-null, but empty string!!
I don't know if any code depends on this fine distinction between a null
string and an empty string, but with the current DOMString it is possible.
My design preference would be to aim for this: a new string, after
appending and deleting another string, should be indistinguishable from a
newly created string. The public state revealed by public methods should
not change.
-Rob
Curt Arnold wrote:
I'm definitely in favor of using erase() (to clear) and empty() (to check
for zero length string) and against a static "null" string. I've converted
all of the = nulls and string == null's in a
previous personal variant and it wasn't all that bad. I think it is one to
just to bite the bullet and do right.
