Re: DOMString (was: xalan-c Problem with Xerces initialization)

[Andy Heninger <he...@us.ibm.com>]

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

Re: DOMString (was: xalan-c Problem with Xerces initialization)

[Joe Gregorio <jo...@mts.com>]

Did you remove print() and println()?

	-joe

Andy Heninger wrote:
> 
> 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

-- 
-------------------------------------
Joe Gregorio            MTS System Corp
Program Manager         www.mts.com