[jdom-interest] Text class in the api
Bradley S. Huffman
hip at a.cs.okstate.edu
Tue Oct 23 11:25:14 PDT 2001
Alex Rosen writes:
> I agree, this would be a good time to go down the Text node route and see
> what happens.
> This info certainly puts a hole in my String vs. StringBuffer argument
> terest). I was assuming that characters() was called multiple times only if
> the character data was longer than the parser's internal buffer, but I guess
> that's wrong. Bummer.
> > There are other ways to do this of course, but I think using
> > a Text class
> > has advantages. We might consider implementing the Text
> > internal storage as
> > char instead of String or StringBuffer. By doing this, we
> > could get the
> > fast(er) append functionality of StringBuffer but near the
> > efficiency of
> > String which would still be the most common use case.
> When would char be faster than StringBuffer?
I agree using a Text class has great advantages, but only if JDOMFactory
is modified to include a method for creating the class.
Why would Text have to internally store things as either String, StringBuffer,
or char? What about storing/retriving the content in/from a file, database,
or on/from the network?
IMHO, have a default Text class that uses String. Then specialized classes
can extend the default Text class to handle the special cases.
More information about the jdom-interest