I believe that number 3 could break some code. There must be a fair amount
of code that's relying on an automatic conversion from const char* to
DOMString. For example:
if (str.equals("foo"))
{
...
}
I know that in Xalan it certainly would, although we're working to remove
this sort of thing. Not that I don't support the change -- I do.
Dave
"Andy Heninger" <[EMAIL PROTECTED]> on 01/13/2000 12:45:10 PM
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc: (bcc: David N Bertoni/CAM/Lotus)
Subject: Re: DOMString (was: xalan-c Problem with Xerces initialization)
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.
>
>
>
>
>
