[jdom-interest] Text class (Modified)

[philip.nelson at omniresources.com]

> >Since the underlying abstraction is a StringBuffer, is it permissible
> >to expose that for those who want to be able to use replace() et alii
> >without creating a new SB then calling setValue?  If so:
> >
> >     public StringBuffer getBuffer() {
> >         return value;
> >     }
> >
> >The question is: would this cause inflexibility if, in future, some
> >other implementation were chosen?  It's easy enough, of course, to
> >return new StringBuffer(getValue()), but that won't work ... if the
> >semantics are to be that the returned buffer is live (changing it
> >changes the owning Text).  So it's presented for discussion.
> >
> 
> I'm highly opposed to exposing the internals of the class like this. 
> It opens up way too many cans of worms, especially since right now 
> I'm not at all sure what the internal implementation should be. I 
> think we need to remain open to the possibility that the internal 
> implementation won't be a StringBuffer, both for conformance and 
> performance reasons.  Furthermore, thread safety is a lot trickier if 
> your internals are exposed like that.

I pretty much agree with this.  In the case of StringBuffer, you could
return it regardless of how it was represented internally unless we totally
change how the developer has to think of text in JDOM, ie getText returns
String.

Actually, thread safety would be a lot easier if the internal representation
was exposed.

Instead of 

syncroncized myUpdateMethod (blah) {
 //update my text node and hope no other thread is skipping my method call
}

you get 
StringBuffer updateable = theTextNode.getBuffer()
syncronized (updatedable) {
 //now you're cool
}

right?