I see what you're getting at, and the real answer here is a "Decorator". However, since the kind folks at sun have made StringBuffer a concrete class which is final, the standard Decorator pattern is out.
However, if you're going to create a Pseudo Decorator for StringBuffer, I would suggest backing it by an actual StringBuffer instance, and providing a "toStringBuffer()" or "asStringBuffer()" method which would return the underlying StringBuffer. -----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 2:53 PM To: Jakarta Commons Developers List Subject: Re: [lang] new StringBuffer + The idea is to have a drop in replacement for StringBuffer for when you need more functionality. At work this class is called UStringBuffer. That implementation decorates a StringBuffer, but I suspect directly holding the String array would be more efficient. Why? StringBuffer does annoying things, such as adding the text "null" if you pass in null (thus new method appendSilentNull()). It doesn't have many of the methods from String (or didn't in early JDKs), so this would aid consistency. It could be written as a Utils class, but it is much nicer to write buf.append().appendSilentNull).append(). etc (OK, I know not everyone likes that style of coding, but quite a lot do.) Finally, this class should probably aim to use the private constructors/methods on String via reflection (breaking access limits). Stephen ----- Original Message ----- From: "Inger, Matthew" <[EMAIL PROTECTED]> > My main question here is this: > > Are the operations you're planning on implementing able to > be implemented by accessing the appropriate API methods on > StringBuffer, or does it require access to the underlying data. > > The basic reason I ask is that if it's the first case, there's > no need for a constructable class, but rather a utility class which provided > static final methods to do your operations. > > If it requires access to the underlying data (ie. the char array > you'd be storing) then an actual class makes sense. However, why > would you want to re-implement the methods that StringBuffer has already > implemented? And if you're answer is that StringBufferPlus is going to > delegate to StringBuffer, i think the first principle applies here, in > which case a utility class is the answer. > > -----Original Message----- > From: Arun Thomas [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 18, 2003 11:11 AM > To: Jakarta Commons Developers List > Subject: RE: [lang] new StringBuffer + > > > +1 > > Good idea.... > > -AMT > > -----Original Message----- > From: ASHWIN Suresh [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 18, 2003 4:35 AM > To: 'Jakarta Commons Developers List' > Subject: RE: [lang] new StringBuffer + > > > How about StringBufferPlus ?? > > It's not an abbreviation, > fits into Stephen's scheme of alphabetical order, > doesnt introduce any new terminology/concept, > and gives us a new convention (-Plus suffix) to denote our enhancement > classes. > > Ash > > > > > -----Original Message----- > > From: Henri Yandell [mailto:[EMAIL PROTECTED] > > Sent: Thursday, December 18, 2003 08:06 > > > > > > > > Sounds to me like what we have is: > > > > Enhanced/ImprovedStringBuffer > > > > if we really want to be extending StringBuffer and adding a few more > > methods. > > > > None of the other names seem to indicate what is actually > > being discussed. > > > > That said, do we really have enough new methods to justify > > the creation of > > a new class? > > > > Hen > > > > On Wed, 10 Dec 2003, Stephen Colebourne wrote: > > > > > Let confusion reign..... > > > Lang should not contain a replacement for String. But that isn't the > > > proposal (it was a typo). > > > > > > The class here is a replacement for StringBuffer. It should be a > > > substitutable replacement in all current uses, thus all the > > methods from > > > StringBuffer must be replicated exactly. However it can > > have additional > > > methods, such as > > > appendSilentNull(Object obj) - which doesn't output the > > text 'null' if > > > null is passed in > > > replace(String,String) - which IIRC isn't on the JDK version and > > > so on. > > > > > > BTW: MutableString is a bad name as it can imply a class > > that holds a String > > > and has a getString and setString method. > > > > > > Stephen > > > > > > > > > ----- Original Message ----- > > > From: "Gary Gregory" <[EMAIL PROTECTED]> > > > > Matthew, > > > > > > > > Please note that I am only replying to Ash's message in > > order to toss > > > ideas > > > > around. I am just trying to get to what Ash is really proposing. I > > > > am not advocating for the addition of such a class, it > > certainly is not > > > > "my" class ;-) > > > > > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Inger, Matthew [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, December 10, 2003 12:14 > > > > > To: 'Jakarta Commons Developers List' > > > > > Subject: RE: [lang] new StringBuffer > > > > > > > > > > I would get no warm and fuzzy feeling from this. It gains you > > > > > nothing, and will make code more confusing. Being that > > String is > > > > > final, you can't make this a subclass, so you'd have to > > do conversions > > > > > all over the place between String and your class. > > > > > > > > > > IMHO, extending a class to add new functionality is not > > a good OOP > > > > > practice (Liskov substitution rule). That's really what you're > > > > > trying to do here, even though you can't actually extend String. > > > > > > > > > > Utility methods are the way to go. It's simple and > > concise, plus > > > > > there's no conversions needed. > > > > > > > > > > -----Original Message----- > > > > > From: Gary Gregory [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, December 10, 2003 3:04 PM > > > > > To: 'Jakarta Commons Developers List' > > > > > Subject: RE: [lang] new StringBuffer > > > > > > > > > > > > > > > With a "replacement" String class, you can add to it > > all sorts of > > > goodies > > > > > now in StringUtils and pass instances of that around. > > The code would > > > look > > > > > a > > > > > little better than having static calls to StringUtils > > all over. I guess > > > it > > > > > is a matter a style. The more I think about it though, > > the less warm and > > > > > fuzzy I feel about it... (since you also need to > > toString() the object > > > > > before passing it to anything to needs a "real" String). > > > > > > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Inger, Matthew [mailto:[EMAIL PROTECTED] > > > > > > Sent: Wednesday, December 10, 2003 11:53 > > > > > > To: 'Jakarta Commons Developers List' > > > > > > Subject: RE: [lang] new StringBuffer > > > > > > > > > > > > java.lang.String is already immutable. Why would you > > want to create > > > an > > > > > > "ImmutableString" class? > > > > > > > > > > > > -----Original Message----- > > > > > > From: Gary Gregory [mailto:[EMAIL PROTECTED] > > > > > > Sent: Wednesday, December 10, 2003 2:51 PM > > > > > > To: 'Jakarta Commons Developers List' > > > > > > Subject: RE: [lang] new StringBuffer > > > > > > > > > > > > > > > > > > Ash, > > > > > > > > > > > > I am confused, are you talking about creating a > > better String or a > > > > > better > > > > > > StringBuffer? You mention "the replacement of > > StringBuffer", but then > > > > > > suggest "ImmutableString", these names (in "") are > > two very different > > > > > > things. > > > > > > > > > > > > It sure would be nice to have an ImmutableString > > class to use instead > > > of > > > > > > the > > > > > > plain old JRE String, but it is not a different > > StringBuffer. Or are > > > you > > > > > > saying that this new class should do both jobs? In > > which case, it > > > would > > > > > > not > > > > > > be immutable ;-) > > > > > > > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ASHWIN Suresh [mailto:[EMAIL PROTECTED] > > > > > > > Sent: Wednesday, December 10, 2003 10:31 > > > > > > > To: 'Jakarta Commons Developers List' > > > > > > > Subject: RE: [lang] new StringBuffer > > > > > > > > > > > > > > First off, in my conception of the replacement of > > StringBuffer, > > > > > > > I imagine error handling will take care of wrongly > > passed in values > > > > > > > in a manner similar to classes in cmmons.lang, > > rather than in > > > Standard > > > > > > > API. That is, it will change the erroneous inputs > > to benign values, > > > > > > > rather than throwing an exception. Please confirm this. > > > > > > > > > > > > > > If Stephen meant that even erroneous input results > > in the same > > > > > behavior > > > > > > > as in java.lang.StringBuffer, then I would say, my > > understanding > > > > > > > of the intention of the replacement was in part to > > soften the > > > reaction > > > > > > > toward wrong argument input. Let me know. > > > > > > > > > > > > > > Talking about name, I would add my opinion that > > while it might be > > > > > > > nice to have a name for the replacer that is much > > like the replacee, > > > > > > > (StringBuf) one might prefer a more descriptive > > name at the expense > > > > > > > of this convenience: (ImmutableString). > > > > > > > > > > > > > > As a compromise between the two, the name Strand > > can be adopted > > > > > (Str... > > > > > > > so near the original one + can be defined to > > represent a mutable > > > > > > > string contrasted with "String" which, by virtue of > > the so-named > > > > > > > class in the API, is immutable.) > > > > > > > > > > > > > > Comments. > > > > > > > Ash > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Stephen Colebourne > > [mailto:[EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > I remembered my favorite name - StringBuf. Its > > always nice if > > > > > > > > the class > > > > > > > > appears in Eclipse next to the one its replacing :-) > > > > > > > > > > > > > > > > Stephen > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Ash .." <[EMAIL PROTECTED]> > > > > > > > > > Sounds good, I will then work on a StringBuffer > > > > > > > > replacement, and then > > > > > > > > > later on get on to providing it with an XUtils. > > > > > > > > > > > > > > > > > > That way, we will also be able to optimize the > > subsequent > > > > > > > > StringBufferUtils > > > > > > > > > implementation using package-private access. > > > > > > > > > I have always been a little disappointed with > > the facilities > > > > > > > > > java.lang.StringBuffer > > > > > > > > > offered, and now I have a chance to do > > something abt it :) > > > > > > > > > > > > > > > > > > > > > > > > > > > And now for the name game: I propose MutableString. > > > > > > > > > > > > > > > > > > Other possible name suggestions, some quite > > fancy, would be: > > > > > > > > > > > > > > > > > > Strand, CharStrand > > > > > > > > > Token, > > > > > > > > > Bead, CharBead, > > > > > > > > > CharGroup, CharBunch, > > > > > > > > > CharLot, StringLot.... > > > > > > > > > > > > > > > > > > I find Strand especially useful because that > > lets us talk > > > > > > > > about a mutable > > > > > > > > > string in a conceptually distinct manner. Of course, its > > > > > > > > replacive role is > > > > > > > > > not immediate obvious by the name, and some > > might suggest that > > > it > > > > > is > > > > > > > > better > > > > > > > > > that the new name reflects its surrogate nature wrt > > > > > > > > StringBuffer. However, > > > > > > > > a > > > > > > > > > new coin may be useful in the long term. Just > > my 2 cents. > > > > > > > > > > > > > > > > > > Ash > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > > > >From: Stephen Colebourne > > [mailto:[EMAIL PROTECTED] > > > > > > > > > >Sent: Tuesday, December 09, 2003 22:15 > > > > > > > > > >To: Jakarta Commons Developers List > > > > > > > > > >Subject: Re: [lang] StringBufferUtils replacement for > > > > > > > > StringUtils -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Ah, I see what you mean. And no that wasn't > > what I meant :-) > > > > > > > > > > > > > > > > > > > >There is the potential for a StringBufferUtils, with > > > > > > > > similar methods to > > > > > > > > > >StringUtils, but where the first passed in > > parameter is a > > > > > > > > StringBuffer. > > > > > > > > > > > > > > > > > > > >However, what I was thinking of (see the todo list in > > > > > > > > status.html) is a > > > > > > > > new > > > > > > > > > >instantiable class > > > > > > > > > > > > > > > > > > > >public AStringBuffer() { > > > > > > > > > > private char[] buffer = new char[32]; > > > > > > > > > > private int size = 0; > > > > > > > > > > > > > > > > > > > > public AStringBuffer() { > > > > > > > > > > } > > > > > > > > > > public void append(Object obj) { > > > > > > > > > > // copy to end of buffer > > > > > > > > > > } > > > > > > > > > >} > > > > > > > > > > > > > > > > > > > >ie. a direct StringBuffer replacement. > > > > > > > > > > > > > > > > > > > >Both are good candidates for [lang]. > > > > > > > > > > > > > > > > > > > >Stephen > > > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > > > >From: "ASHWIN Suresh" <[EMAIL PROTECTED]> > > > > > > > > > > > With the one difference that the methods here don't > > > > > > > > return aything, > > > > > > > > but > > > > > > > > > > > instead modify the StringBuffer > > > > > > > > > > > passed in, directly. > > > > > > > > > > > I will start work on it tonight. > > > > > > > > > > > Ash > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Stephen Colebourne > > > > > [mailto:[EMAIL PROTECTED] > > > > > > > > > > > > Sent: Tuesday, December 09, 2003 20:07 > > > > > > > > > > > > To: Jakarta Commons Developers List > > > > > > > > > > > > Subject: Re: [lang] String Utils replacement for > > > > > > > > StringUtils -- was > > > > > > > > > > > > ([lang] StringUtils.split() functionality wrt > > > > > > > > separator repeats) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The string buffer class needs to begin by > > having all the > > > > > same > > > > > > > > > > > > methods as > > > > > > > > > > > > StringBuffer, and they should do exactly > > the same. Then, > > > > > > > > > > > > methods to handle > > > > > > > > > > > > null would be added: > > > > > > > > > > > > appendSilentNull() > > > > > > > > > > > > > > > > > > > > > > > > At that point, we could evaluate it and > > see what else > > > > > > > > should be > > > > > > > > added. > > > > > > > > > > > > > > > > > > > > > > > > Stephen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "ASHWIN Suresh" <[EMAIL PROTECTED]> > > > > > > > > > > > > > Incidentally (or perhaps it was to > > come), I was about to > > > > > > > > > > > > send out another > > > > > > > > > > > > > email > > > > > > > > > > > > > proposing a StringUtils-like class that handles > > > > > > > > > > > > StringBuffer instead. > > > > > > > > > > > > > I would be interested in writing it, > > but I need to > > > > > evaluate > > > > > > > > > > > > how much time > > > > > > > > > > > > I > > > > > > > > > > > > > can afford > > > > > > > > > > > > > to it (will let u know). > > > > > > > > > > > > > > > > > > > > > > > > > > In the meanwhile, assuming I can go > > ahead, you can list > > > > > out > > > > > > > > > > > > right away > > > > > > > > > > > > what > > > > > > > > > > > > > differences > > > > > > > > > > > > > you see between StringUtils and the StringBuffer > > > > > > > > > > > > counterpart. I can, for > > > > > > > > > > > > > now, perhaps cover the > > > > > > > > > > > > > simpler methods which are similar to > > the StringUtils > > > ones. > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding tightening admissibility of > > new methods to a > > > > > > > > > > > > class because it is > > > > > > > > > > > > > large, I > > > > > > > > > > > > > am of the opinion that for a class of > > only static > > > methods > > > > > > > > > > > > such as this > > > > > > > > > > > > one, > > > > > > > > > > > > > why should there be any hesitation. > > StringUtils is but a > > > > > > > > > > > > repository of all > > > > > > > > > > > > > such > > > > > > > > > > > > > features, so as long as we have clear > > documentation, I > > > see > > > > > > > > > > > > no reason why > > > > > > > > > > > > > largeness > > > > > > > > > > > > > should lead to limits to having more methods. > > > > > > > > > > > > > Let me know. > > > > > > > > > > > > > > > > > > > > > > > > > > Ash > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Stephen Colebourne > > > > > > > > [mailto:[EMAIL PROTECTED] > > > > > > > > > > > > > > Sent: Monday, December 08, 2003 22:05 > > > > > > > > > > > > > > To: Jakarta Commons Developers List > > > > > > > > > > > > > > Subject: Re: [lang] > > StringUtils.split() functionality > > > > > wrt > > > > > > > > > > > > separator > > > > > > > > > > > > > > repeats > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With StringUtils, we now face tough decisions. > > > > > > > > The class is > > > > > > > > > > > > > > already very > > > > > > > > > > > > > > large, and adding more and more methods is not > > > > > necessarily > > > > > > > > > > > > > > the answer. I am > > > > > > > > > > > > > > now applying a fairly high level of > > justification to > > > new > > > > > > > > > > > > additions to > > > > > > > > > > > > > > StringUtils. ATM more split methods > > or overloads > > > > > > > > don't meet > > > > > > > > > > > > > > what I'm looking > > > > > > > > > > > > > > for. > > > > > > > > > > > > > > > > > > > > > > > > > > > > That said, there are still some > > misisng methods in > > > > > > > > > > > > > > StringUtils, notably > > > > > > > > > > > > > > startsWith, endsWith and concat/append. (all > > > null-safe). > > > > > > > > > > > > > > > > > > > > > > > > > > > > In addition, a StringBuffer > > replacement needs writing, > > > > > if > > > > > > > > > > > > > > you're interested > > > > > > > > > > > > > > ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stephen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > > > > > > > > > > To unsubscribe, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > For additional commands, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > > > > > > > > > To unsubscribe, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > For additional commands, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > > > > > > > > To unsubscribe, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > For additional commands, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------------------- > > > > > -- > > > > > > > > > >To unsubscribe, e-mail: commons-dev- > > > > > [EMAIL PROTECTED] > > > > > > > > > >For additional commands, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------- > > > > > > > > > > > > > > > > > > Run, rabbit run. > > > > > > > > > Dig that hole, forget the sun, > > > > > > > > > And when at last the work is done > > > > > > > > > Don't sit down it's time to dig another one. > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > > > Stay in touch with absent friends - get MSN Messenger > > > > > > > > > http://www.msn.co.uk/messenger > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > > > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > For additional commands, e-mail: commons-dev- > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
