On Sun, Apr 3, 2011 at 7:47 PM, Henri Yandell <flame...@gmail.com> wrote:
> I've rolled the code back. Now I'm thinking the following are
> candidates to roll back to String:
>
> public static String stripAccents(CharSequence input) {
> public static String capitalize(CharSequence cs) {
> public static String uncapitalize(CharSequence cs) {
>
> and the following are candidates to move to CharSequence:
>
> public static boolean equalsIgnoreCase(String str1, String str2) {
> public static int indexOf(String str, int searchChar) {
> public static int indexOf(String str, int searchChar, int startPos) {
> public static int indexOf(String str, String searchStr) {
> public static int indexOf(String str, String searchStr, int startPos) {
> public static int ordinalIndexOf(String str, String searchStr, int
> ordinal) {
> public static int indexOfIgnoreCase(String str, String searchStr) {
> public static int indexOfIgnoreCase(String str, String searchStr,
> int startPos) {
> public static int lastIndexOf(String str, int searchChar) {
> public static int lastIndexOf(String str, int searchChar, int startPos)
> {
> public static int lastIndexOf(String str, String searchStr) {
> public static int lastOrdinalIndexOf(String str, String searchStr,
> int ordinal) {
> public static int lastIndexOf(String str, String searchStr, int
> startPos) {
> public static int lastIndexOfIgnoreCase(String str, String searchStr) {
> public static int lastIndexOfIgnoreCase(String str, String
> searchStr, int startPos) {
> public static boolean contains(String str, int searchChar) {
> public static boolean contains(String str, String searchStr) {
> public static boolean containsIgnoreCase(String str, String searchStr) {
> public static boolean containsWhitespace(String str) {
> public static boolean containsAny(String cs, char[] searchChars) {
> public static boolean containsAny(String cs, String searchChars) {
> public static int indexOfAnyBut(String str, String searchChars) {
> public static int indexOfAny(String str, String[] searchStrs) {
> public static int lastIndexOfAny(String str, String[] searchStrs) {
> public static int countMatches(String str, String sub) {
> public static boolean startsWith(String str, String prefix) {
> public static boolean startsWithIgnoreCase(String str, String prefix) {
> public static boolean startsWithAny(String string, String...
> searchStrings) {
> public static boolean endsWith(String str, String suffix) {
> public static boolean endsWithIgnoreCase(String str, String suffix) {
> public static boolean endsWithAny(String string, String...
> searchStrings) {
>
> Basic rules being 'if String is returned, then String should be passed
> in' and 'if other than String is returned, pass in CharSequence'.
>
Like it. +1
Gary
>
> Hen
>
> On Sun, Apr 3, 2011 at 2:45 PM, Henri Yandell <flame...@gmail.com> wrote:
> > Agreed (apologies for the delay; life got, and is going to remain, very
> busy).
> >
> > We should remove the CharSequence code I added. We should also review
> > the first batch of CharSequence changes.
> >
> > I think it's fine to have this:
> >
> > public int length(CharSequence seq)
> >
> > I'll look into the removal if no one else gets to it - with a new baby
> > in the house that's going to depend very much on how calm she is.
> >
> > Hen
> >
> > On Fri, Mar 18, 2011 at 1:21 AM, Stephen Colebourne
> > <scolebou...@joda.org> wrote:
> >> On 18 March 2011 03:56, Henri Yandell <flame...@gmail.com> wrote:
> >>> 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.
> >>
> >> As I've probably said before, I think that most people are looking for
> >> a StringUtils operating on Strings and nulls. I personally never hold
> >> CharSequence as a variable, although obviously I use StringBuffer,
> >> StringBuilder and StrBuilder. But, I rarely have a CharSequence that
> >> is null - it doesn't make that much sense to do so as mutable strings
> >> are transient.
> >>
> >> The significant class IMO.is StrBuilder, which is [lang] owned. That
> >> is where all these utility methods go, Thus you can do:
> >>
> >> StrBuilder b = ...
> >> b.setLowerCase()
> >>
> >> If you need to operate on a StringBuffer or StringBuilder? Well,
> >> don't! [lang] says use StrBuilder. That was the original design, and
> >> frankly it still makes sense.
> >>
> >> Perhaps this is harsh and there is a role for a helper class for other
> >> CharSequence classes, but its one I personally would use rarely. Thats
> >> because null is rarely the issue with CharSequences, and it can easily
> >> be changed in most user code to a StrBuilder.
> >>
> >>> a) For every method, once CharSequence is there, return null if its a
> >>> known mutable and instead mutate the CharSequence.
> >> Horrible API
> >>
> >>> b) For every method, once CharSequence is there, return a new string
> >>> AND for known mutables mutate the CharSequence.
> >> Far from great (lots of code to create an abstraction that isn't
> abstract)
> >>
> >>> 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.
> >> Well, you could consider StrBuilder to be a form of StringMutate I
> >> suppose. But having StringUtils create and use a buffer for every
> >> method is very poor for performance. The performance really matters
> >> here, and thats why I think StringUtils should revert to solely
> >> Strings.
> >>
> >>> 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 :)
> >>>
> >> There are many ways to cut this, for example, StrBuilder could be
> >> reworked to have the ability to update StringBuilder/StringBuffer:
> >>
> >> StringBuffer buf = ...
> >> StrBuilder view = StrBuilder.asViewOf(buf);
> >> view.setLowerCase() // updates view and buf
> >>
> >> Internally, StrBuilder could
> >> (a) hold an Object and have a low level mutation plugin for char[],
> >> StringBuilder and StringBuffer
> >> (b) StrBuilder could store a StringBuilder rather than a char[],
> >> although I suspect that would hurt performance
> >> (c) Every StrBuilder method could end with resetLinkedView(), which
> >> would do buf.setLength(0);buf.append(toString()); Simple, but slow.
> >>
> >> It depends if there is the desire to support
> >> StringBuffer/StringBuilder or not.I suspect that (a) is the best
> >> choice.
> >>
> >> BTW, tearing CharSequence out of StringUtils sounds harsh. But I've
> >> been forced to tear generics out of systems late in the day when I've
> >> realised that they made the API worse not better. This seems like a
> >> parallel case here - we've been making StringUtils more complex, and
> >> its fundamentally not giving the desired benefits.
> >>
> >> Stephen
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
