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 20:04:55 GMT
Hello Gilles

Gilles <gilles@harfang.homelinux.org> schrieb am Di., 22. Nov. 2016 um
20:55 Uhr:

> On Tue, 22 Nov 2016 19:40:30 +0000, Benedikt Ritter wrote:
> > 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.
>
> IMHO "more complex" is key, not so much "string" vs "text".
>
> Hence I suggest [text] is a better place for "RandomStringUtils"
> than [lang], and the former should allow dependencies as a
> foundation for that complexity; in that case, that would be
> "Commons RNG".
>

I find it hard to draw a line here. What might be complex to me, could be
simple for others. I fear that there will always be discussions.


>
> Regards,
> Gilles
>
> >
> >
> >>
> >> 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