commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [text][lang] string escaping
Date Tue, 22 Nov 2016 19:40:30 GMT
Gary Gregory <garydgregory@gmail.com> schrieb am Sa., 19. Nov. 2016 um
19:09 Uhr:

> On Nov 19, 2016 9:50 AM, "Gilles" <gilles@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 <britter@apache.org>
> wrote:
> >>
> >>> Hello Gray,
> >>>
> >>> Gary Gregory <garydgregory@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message