commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ASHWIN Suresh <a.sur...@sigmatel.net.ma>
Subject RE: [lang] StringBufferUtils replacement for StringUtils --
Date Tue, 09 Dec 2003 20:39:34 GMT
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:scolebourne@btopenworld.com]
> 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" <a.suresh@sigmatel.net.ma>
> > 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:scolebourne@btopenworld.com]
> > > 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message