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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
