> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebou...@btopenworld.com]
> Sent: Sunday, March 14, 2010 06:44
> To: Commons Developers List
> Subject: Re: [lang] LANG-510
>
> I do fear that this discussion may be over-thinking. Most users will, I
> believe, be working with String and want a String back. Many of these
> calls may be in time-critical code, so the conversion from a
> CharSequence (even though trivial) may be a small overhead.
Hi Stephen,
Thank you for your feedback. At the risk of continuing to over think... :)
I think I may be misunderstanding your comment but... Here is an example where
I do not see any overhead changes: changing methods like isEmpty from
isEmpty(String) to isEmpty(CharSequence) is "free" I claim.
For StringUtils methods where the return type is not a String and the input is
a String that happens to only use the CharSequence API, changing the parameter
signature from String to CharSequence seems painless.
For the other conversions, it might be too much to chew off until customers ask
for it.
>
> We also have StrBuilder for those cases where a user needs a kind of
> builder approach. Personally, I use StrBuilder instead of
> StringBuffer/StringBuilder whenever I can.
>
> With CharSequence you need to ask if it makes sense for the operation
> to
> be called on an input stream or similar - because that is, as much as
> anything, what the interface was designed for.
>
> In summary, I don't overly object to the methods being changed to take
> a
> CharSequence, although I do think its a waste. StringUtils should never
> return CharSequence.
Yes, good catch. This signature of the method defaultIfEmpty is a bug:
CharSequence defaultIfEmpty(CharSequence str, CharSequence defaultStr)
It is a bug because the following does not compile without casting the result
value:
String s = StringUtils.defaultIfEmpty("abc", "NULL");
But this compiles and tests pass:
<T extends CharSequence> T defaultIfEmpty(T str, T defaultStr)
There are currently no StringUtils APIs that return CharSequence only.
I also have string doubts over the utilty of a
> CharSequenceUtils.
I have backed out some code from CSU. I am going to keep working on this
locally.
Gary
>
> Stephen
>
>
> Gary Gregory wrote:
> > 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().
> >
> > Thoughts?
> >
> > Gary
> >> -----Original Message-----
> >> From: Jörg Schaible [mailto:joerg.schai...@gmx.de]
> >> Sent: Sunday, March 07, 2010 05:54
> >> To: dev@commons.apache.org
> >> Subject: RE: [lang] LANG-510
> >>
> >> Gary Gregory wrote:
> >>
> >>> When I replaced the current implementation of
> StringUtils.left(String,int)
> >>> with:
> >>>
> >>> @SuppressWarnings("unchecked")
> >>> public static <T extends CharSequence> T left(T cs, int len) {
> >>> if (cs == null) {
> >>> return null;
> >>> }
> >>> if (len < 0) {
> >>> return (T) cs.subSequence(0, 0);
> >>> }
> >>> if (cs.length() <= len) {
> >>> return cs;
> >>> }
> >>> return (T) cs.subSequence(0, len);
> >>> }
> >>>
> >>> Everything compiled, all tests passed, and no Unnecessary cast
> warnings
> >>> came up (as provided by Eclipse 3.6M5)
> >>>
> >>> The problem is what happens when you pass in a non-Strings, like a
> >>> StringBuilder. The implementation of subsequence for StringBuilder
> returns
> >>> a new String, not new StringBuilder.
> >> Then why not use already proposed:
> >>
> >> public static String left(CharSequence str, int len) {
> >> if (str == null) {
> >> return null;
> >> }
> >> return str.subSequence(0, len).toString();
> >> }
> >>
> >> ??
> >>
> >> - Jörg
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
