commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Inger, Matthew" <in...@Synygy.com>
Subject RE: [lang] new StringBuffer
Date Wed, 10 Dec 2003 19:53:29 GMT
java.lang.String is already immutable.  Why would you want to create an
"ImmutableString" class?

-----Original Message-----
From: Gary Gregory [mailto:ggregory@seagullsw.com]
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:a.suresh@sigmatel.net.ma]
> 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:scolebourne@btopenworld.com]
> >
> >
> > 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 .." <equinus100@hotmail.com>
> > > 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:scolebourne@btopenworld.com]
> > > >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" <a.suresh@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.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
> > > > >
> > > >
> > > >
> > >
> > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------
> > >
> > > 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: 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message