/[Apache-SVN]
ViewVC logotype

Revision 920543


Jump to revision: Previous Next
Author: ggregory
Date: Mon Mar 8 22:15:08 2010 UTC (14 years, 7 months ago)
Changed paths: 4
Log Message:
Change StringUtils arguments from String to CharSequence.

Details: Working with (trunk) StringUtils (SU) I see the following emerge: 

- In SVN already and continuing: Change StringUtils arguments from String to CharSequence (CS).

- This leads to replacing calls to String.substring(int[,int]) with calls to CharSequence.subSequence(int)

- This leads to creating a CharSequenceUtils class (in SVN now, more on this new class below) and CharSequenceUtils.subSequence(CharSequence,int) to avoid changing "str.substring(start)" over and over to "str.subSequence(start, str.length())". For examples, see new versions of capitalize and uncapitalize.

- We end up using a toString() on CharSequence to return a String from StringUtil when working with a CharSequence.

So we have StringUtils using CharSequence inputs as much as possible instead of String, which is nice. 

The CharSequence method subSequence returns a CharSequence; though the Javadoc states "Returns a new CharSequence that is a subsequence of this sequence.", this does not guaranteed the return value to be the same kind of CharSequence as the receiver). Since we are after all in a class called StringUtil, calling toString() is a must.

I propose that we create when possible the methods that are now StringUtils CharSequence methods into CharSequenceUtils and let StringUtil call CharSequenceUtils and then do its toString() and other String specific logic. Later we could have other CharSequence type of utils (for CharBuffer, StringBuiler, StringBuffer, etc) that use the 'primitives' from CharSequenceUtils.
This means that for methods that are based solely on methods that are now in CharSequence, these can be moved to CharSequenceUtils without effort (all is* methods only call CharSequence#length() and charAt() for example and are now typed as CS, still in SU). 

We can leave @deprecateds method in SU as a nicety to avoid too much porting pain: First change the package to lang3 then you can 'optimize' by changing call sites from SU to CSU.

As a start, I put in SVN a CharSequenceUtils (CSU) implementation for length() and subSequence().


Changed paths

Path Details
Directorycommons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSequenceUtils.java added
Directorycommons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringUtils.java modified , text changed
Directorycommons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/CharSequenceUtilsTest.java added
Directorycommons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java modified , text changed

infrastructure at apache.org
ViewVC Help
Powered by ViewVC 1.1.26