Gary Gregory <garydgreg...@gmail.com> schrieb am Sa., 19. Nov. 2016 um 19:09 Uhr:
> On Nov 19, 2016 9:50 AM, "Gilles" <gil...@harfang.homelinux.org> wrote: > > > > On Sat, 19 Nov 2016 08:59:50 -0800, Gary Gregory wrote: > >> > >> On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter <brit...@apache.org> > wrote: > >> > >>> Hello Gray, > >>> > >>> Gary Gregory <garydgreg...@gmail.com> schrieb am Sa., 19. Nov. 2016 um > >>> 01:07 Uhr: > >>> > >>> > Just a thought: > >>> > > >>> > Does all the current (and future) string escaping code (XML, HTML, > ...) > >>> > really belong in [lang]? Would it be more natural to have it in > [text]? > >>> > > >>> > >>> My view on the whole think currently is, that we put stuff that is > related > >>> to strings in Lang. Code that works on texts should go to Text. To me a > >>> text is more than just a string. A text contains works, that make up > >>> sentences, which in turn build paragraphs. > >>> > >>> Using this description, I'd argue that escaping belongs into lang and > not > >>> into text, because it works on individual characters rather than on > texts. > >>> > >>> But this would also raise the question if the various edit distance > >>> algorithms works on texts or on strings. So maybe my distinction is not > >>> good at all. > >>> > >>> Do we need to better specify the scope of text? > >>> > >> > >> Great question of course. > >> > >> I'd like to think of [lang] as "What is missing from the JRE's most > basic > >> classes and specifically from the java.lang package and some java.util > >> classes". > >> > >> Quoting from our site: > >> > >> "The standard Java libraries fail to provide enough methods for > >> manipulation of its core classes. Apache Commons Lang provides these > extra > >> methods. > >> Lang provides a host of helper utilities for the java.lang API, notably > >> String manipulation methods, basic numerical methods, object reflection, > >> concurrency, creation and serialization and System properties. > Additionally > >> it contains basic enhancements to java.util.Date > > > > > > How about "Date" becoming a nice standalone component? ;-) > > [Components should be concept-based.] > > Joda-time covers more than we will ever do here IMO. And Java 8 has new > time APIs... maybe when lang is Java 8 based we can look again. For now I'd > rather leave dates as is. > Yes, let's get back to topic. I think we need a clear distinction between string related stuff that goes into Lang and more complex stuff that goes into text. > > Gary > > > > How about deprecating "RandomUtils"? > > [(About to be) superseded by "Commons RNG".] > > > > How about to > > * moving "RandomStringUtils" to [text] too and > > * implement it against a custom interface (as per Jochen's remark) > > rather than "java.util.Random" > > ? > > > > > >> and a series of utilities > >> dedicated to help with building methods, such as hashCode, toString and > >> equals." > >> > >> I do not think edit distances fit into this at all. > > > > > > +1 > > > > > >> I am also questioning whether string escaping belongs in lang as well > since > >> there are so many escaping domains XML, HTML, JSON, and so on. > > > > > > They don't belong. > > > > > >> IMO, anything that is word based does not belong in lang like > >> capitlization. The WordUtils class should be in [text] IMO. The whole > lang > >> text package should be in [text] IMO. > > > > > > +1 > > [To anything that imposes a strict diet on the humongous "components".] > > > > > > Regards, > > Gilles > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > >