On Thu, Mar 17, 2011 at 12:08 AM, Henri Yandell <flame...@gmail.com> wrote:
> On Tue, Mar 15, 2011 at 9:39 PM, Henri Yandell <flame...@gmail.com> wrote:
>
>> 4) Stephen urged that we revisit StringUtils to see what else can move
>> to CharSequence.
>>
>> 5) Stephen recommended that CharSequenceUtils move into StringUtils.
>> This seems fair, CharSequenceUtils is never going to get a lot of
>> methods unless we move half of StringUtils out and make it feel very
>> odd. [DONE].
>
> So having done #5, and working on #4, I'm starting to come up with a
> bunch of methods that might make sense on CharSequenceUtils.
>
> Basically it's a set of methods on java.lang.String that are being
> implemented to support CharSequence. The first step is to check if the
> CharSequence is a String; if so then optimize and use the
> java.lang.String code. Otherwise use a basic implementation built on
> top of the CharSequence API. They're currently living at the end of
> the StringUtils class, but I'm leaning towards making them their own
> class. CharSequenceUtils, or is there a better name?
>
> I'd also appreciate feedback on the current changes in case it's felt
> I'm reaching too much to support CharSequence as an API; I'm 20 of 76
> unique method names along :)
Something occurred to me today. We're moving from String to
CharSequence in the API, but not thinking of the use case.
If I call:
StringUtils.toLowerCase(stringBuffer);
I'd argue that the likely style would be to modify the object being
passed in, not to return it (even if we could return a StringBuffer
instead of a new String). More specifically, if the CharSequence is
mutable, then mutate the passed in value, whereas if the CharSequence
is immutable, return a new version.
This makes me wonder if there's any value in moving to CharSequence.
Of the 5 subclasses, 4 of them are mutables:
CharBuffer, String (immutable), StringBuffer, StringBuilder and
our StrBuilder.
CharBuffer is only really appendable rather than wholly mutable;
unless optional methods are implemented.
So while this is in the abstract a good thing; I'm not convinced
converting to CharSequence will change anything. It'll still only get
called as a String because it returns String; but more importantly
because it doesn't modify in place.
It's tempting to either:
a) For every method, once CharSequence is there, return null if its a
known mutable and instead mutate the CharSequence.
b) For every method, once CharSequence is there, return a new string
AND for known mutables mutate the CharSequence.
c) Create a StringMutate class (by moving StringUtils) which modifies
the passed in and known mutable subclasses of CharSequence, then put
StringUtils on top of it and have it create a new StringBuilder each
time and pass it down to the class (or classes) with the real code.
Both b) and c) could be done in a later version. a) would be a big
change in functionality.
I'm liking c). We could add a super class above StrBuilder -
MutableCharSequence - and then implement three methods for every
method in StringUtils to support the three big mutables
(StringBuilder, StringBuffer + MutableCharSequence); or we could drop
StringBuffer. That increases the size of the class to 13,000 lines :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
