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]
