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
