Are you suggesting the standard decorator pattern is to extend the class you wish to decorate?
*fears* Hen On Thu, 18 Dec 2003, Inger, Matthew wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
