commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@gmail.com>
Subject Re: [text][lang] string escaping
Date Thu, 24 Nov 2016 13:54:55 GMT

> On Nov 22, 2016, at 4:38 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> 
> On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <britter@apache.org>
> wrote:
> 
>> 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.
>> 
> 
> Then we can focus on a feature request with a different lens: Would you
> reasonably expect this to be in java.lang or java.util.

Let’s consider an example that I would ask about here. Consider the “longestCommonPrefix”
method:

public static int longestCommonPrefix(final String s1, final String s2) {
    int i = 0;
    while (i < s1.length() && i < s2.length() && s1.charAt(i) == s2.charAt(i))
 {
        i++;
    }
    return i;
}
I would think that this would end up in text because I doubt many folks would use this in
standard application code. What are other’s thoughts?

-Rob

> 
> Gary
> 
>> 
>> 
>>> 
>>> 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
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
> 
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
> 
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


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