[jdom-interest] Text class (Modified)

[Elliotte Rusty Harold]

At 6:51 PM -0400 5/27/01, Amy Lewis wrote:


>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.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+