RE: [lang] StringBufferUtils replacement for StringUtils --

[ASHWIN Suresh <a....@sigmatel.net.ma>]

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....@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

Re: [lang] StringBufferUtils replacement for StringUtils --

[Stephen Colebourne <sc...@btopenworld.com>]

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" <a....@sigmatel.net.ma>
> 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....@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
>


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