MutableString is ok. I like CharGroup also.
If it's meant to be an improved replacement for StringBuffer, I always prefer names like StringBuffer2 or StringBufferX. I guess they can be considered a bit ugly -- but at least they're generally understandable.
Stephen Colebourne wrote:
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: [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: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
