Let confusion reign.....
Lang should not contain a replacement for String. But that isn't the
proposal (it was a typo).

The class here is a replacement for StringBuffer. It should be a
substitutable replacement in all current uses, thus all the methods from
StringBuffer must be replicated exactly. However it can have additional
methods, such as
  appendSilentNull(Object obj) - which doesn't output the text 'null' if
null is passed in
  replace(String,String) - which IIRC isn't on the JDK version
and so on.

BTW: MutableString is a bad name as it can imply a class that holds a String
and has a getString and setString method.

Stephen


----- Original Message -----
From: "Gary Gregory" <[EMAIL PROTECTED]>
> Matthew,
>
> Please note that I am only replying to Ash's message in order to toss
ideas
> around. I am just trying to get to what Ash is really proposing.
> I am not advocating for the addition of such a class, it certainly is not
> "my" class ;-)
>
> Gary
>
> > -----Original Message-----
> > From: Inger, Matthew [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 10, 2003 12:14
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: [lang] new StringBuffer
> >
> > I would get no warm and fuzzy feeling from this.  It gains you
> > nothing, and will make code more confusing.  Being that String is
> > final, you can't make this a subclass, so you'd have to do conversions
> > all over the place between String and your class.
> >
> > IMHO, extending a class to add new functionality is not a good OOP
> > practice (Liskov substitution rule).  That's really what you're
> > trying to do here, even though you can't actually extend String.
> >
> > Utility methods are the way to go.  It's simple and concise, plus
> > there's no conversions needed.
> >
> > -----Original Message-----
> > From: Gary Gregory [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 10, 2003 3:04 PM
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: [lang] new StringBuffer
> >
> >
> > With a "replacement" String class, you can add to it all sorts of
goodies
> > now in StringUtils and pass instances of that around. The code would
look
> > a
> > little better than having static calls to StringUtils all over. I guess
it
> > is a matter a style. The more I think about it though, the less warm and
> > fuzzy I feel about it... (since you also need to toString() the object
> > before passing it to anything to needs a "real" String).
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Inger, Matthew [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, December 10, 2003 11:53
> > > To: 'Jakarta Commons Developers List'
> > > Subject: RE: [lang] new StringBuffer
> > >
> > > java.lang.String is already immutable.  Why would you want to create
an
> > > "ImmutableString" class?
> > >
> > > -----Original Message-----
> > > From: Gary Gregory [mailto:[EMAIL PROTECTED]
> > > 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:[EMAIL PROTECTED]
> > > > 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:[EMAIL PROTECTED]
> > > > >
> > > > >
> > > > > 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 .." <[EMAIL PROTECTED]>
> > > > > > 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:[EMAIL PROTECTED]
> > > > > > >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" <[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: commons-dev-
> > [EMAIL PROTECTED]
> > > > > > >For additional commands, e-mail:
> > > > > [EMAIL PROTECTED]
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------
> > > > > >
> > > > > > 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:
[EMAIL PROTECTED]
> > > > > > For additional commands, e-mail: commons-dev-
> > [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]

Reply via email to