My take is that these suggestions all address legitimate problems, and are
well worth serious consideration.
Numbers 1,2,3 and 5 don't look like they would introduce any
incompatibilities with applications and I think that we should just put them
in.
Number 4 I agree with, but yanking the constructor is a breaking change. My
guess is the DOMString(int) constructor hasn't had much use and that making
the change would be OK. You're certainly right that it's confusing as it
stands.
-- Andy
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 12, 2000 5:41 PM
Subject: DOMString (was: xalan-c Problem with Xerces initialization)
>
> If we're going to change DOMString around, here's my wish-list. Most are
> for performance. Some are to make DOMString more regular as an ADT. I've
> prototyped all of them locally.
>
>
> 1) Move DOMString operator + (const DOMString &other) to be a helper
> function rather than a member, i.e. operator+(const DOMString& lhs, const
> DOMString& rhs). Then add overloads of operator+ to work symmetrically
> with XMLCh*, i.e. operator+(const DOMString& lhs, const XMLCh *rhs) and
> operator+(const XMLCh* lhs, const DOMString& rhs). In general, try to get
> the operators to work symmetrically with DOMString and XMLCh*, since an
> application that uses both SAX and DOM (like Xalan) often needs to them
> together in a calculation. In most cases, an overloaded method that works
> with both XMLCh* and DOMString can do the job much faster than one that
> needs to convert to temporary DOMString's.
>
> 2) Add a member appendData() overloaded to append a single XMLCh.
> Currently, doing this requires temporary conversion to DOMString's, a big
> waste. Also, operator+=() would be nice.
>
> 3) Make the DOMString(const char*) constructor either be explicit, or make
> it be a non-member transcoding utility.
>
> 4) Also, the DOMString(int) constructor is a mental trap, since
programmers
> will sometimes think this does an itoa conversion. Also, because
> characters are integral types, something like DOMString('A') does not work
> like it looks. In fact, the std::base_string<>(int) constructor was
> purposely left out of the standard string class because of
> these common confusions. Instead, I'd rather have a member called reserve
> () or something similar.
>
> 5) It would be nice to have a reset() method. I see that the Xerces code
> sometimes just assigns the old DOMString a literal 0. But that kicks off
> the DOMString(int) constructor and then an assignment. I bet a
> DOMString.reset() method would be much faster, avoiding the temporary
> DOMString.
>
>
>
>
>
