commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [text][lang] string escaping
Date Sat, 19 Nov 2016 18:08:52 GMT
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.

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