See below... > -----Original Message----- > From: Alex Chaffee / Purple Technology [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 09, 2003 3:09 PM > To: Jakarta Commons Developers List > Subject: Re: [lang] Summarising Purple Was: [lang] Adding > Purple to StringUtils > > > * abbreviate > > OK! How about I add this one myself? I'm a Tomcat > committer; whom do I ask to add me to the karma list for > commons? (I think I heard that Tomcat committers don't need > a confirmation vote.) > > > * integrate truncateNicely and abbreviate > > This I'd have to do research on; probably should wait until > abbreviate() is done. > > > * differentAt, differentText > > I like these names. Another suggestion is to use > "difference" since that describes the return value (and > "different" implies it's returning a boolean, like "is > different" vs. "get the difference"). > > So can I get a +1 on: > public String difference(String s1, String s2) > public int differenceAt(String s1, String s2) >
+1, for the reasons enumerated > > * Change chomp to match perl > > I can do this too. > > > * Rename current chomp > > I've been getting in the habit of restricting the use of > "get" in method names (properties only). So I prefer a verb > like "bisect" or "divide" rather than "getAfterFirst" and such. > > I think "bisect" is good since it explicitly means "two > parts" rather than "split" which returns many parts. Wouldn't "removeFromLast" describe the action more succiently than "bisect" or "divide"? > > > * Change getPrechomp [aka getAfterFirst or bisectAfter] to > not return the separator. > > That sounds fine; how do we handle deprecation warnings for > this and for chomp? (In case people rely on the old behavior.) > > > * escapeHtml, unescapeHtml > * escapeJava, escapeJavaScript > * future: escapeSql, escapeXml, unescape* > > Henri suggested to make StringEscapeUtils.java to hold all > these. I like that a lot. Any more +1s? +1. I like the separation. > > As for deprecation, the only method that would need to be > deprecated is StringUtils.escape. Since Java escaping is the > natural thing you'd expect StringUtils to do, it makes sense > to leave it in there as StringUtils.escape. So I propose > leaving that as it is, and instead just making it call > StringEscapeUtils.escapeJava. > +1, because it avoids deprecation > > * uncurlQuotes > > There was no vote on this. It's not escaping, but > converting, so I think it belongs in the base StringUtils. > Any objections? > > > * toUnderscoreName, toCamelCaseName > > This is not escaping, so it doesn't belong in > StringEscapeUtils. I'd be happy to put them in StringUtils... > > ... especially since I just realized that these two methods, > in combination with upperCase and lowerCase and and > replace(s, "_", " ") and uncapitalise and capitaliseAllWords, > can be used to convert between all of > > yo mama > Yo Mama > Yo_Mama > yo_mama > YO_MAMA > YoMama > yoMama > > The only question now is how many convenience methods we want > to clutter the API with. I still think these are more functionality than is intended in StringUtils. Would it make sense to put them into a StringConvertUtils? > > > > -- > Alex Chaffee mailto:[EMAIL PROTECTED] > Purple Technology - Code and Consulting http://www.purpletech.com/ > jGuru - Java News and FAQs http://www.jguru.com/alex/ > Gamelan - the Original Java site http://www.gamelan.com/ > Stinky - Art and Angst http://www.stinky.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
