You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2016/11/19 00:07:33 UTC

[text][lang] string escaping

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]?

Gary

-- 
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

Re: [text][lang] string escaping

Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 22 Nov 2016 20:04:55 +0000, Benedikt Ritter wrote:
> Hello Gilles
>
> Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov. 
>> 2016
>> > um
>> > 19:09 Uhr:
>> >
>> >> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
>> >> <br...@apache.org>
>> >> wrote:
>> >> >>
>> >> >>> Hello Gray,
>> >> >>>
>> >> >>> Gary Gregory <ga...@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.

The complexity we talk about here should not be subjective.

In particular, discussions would be reduced if a scope is
defined precisely.

Gilles

>
>>
>> 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


Re: [text][lang] string escaping

Posted by Benedikt Ritter <br...@apache.org>.
Hello Rob,

Rob Tompkins <ch...@gmail.com> schrieb am Do., 24. Nov. 2016 um
14:55 Uhr:

>
> > On Nov 22, 2016, at 4:38 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> >> Hello Gilles
> >>
> >> Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016
> >>>> um
> >>>> 19:09 Uhr:
> >>>>
> >>>>> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
> >>>>> <br...@apache.org>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Hello Gray,
> >>>>>>>>
> >>>>>>>> Gary Gregory <ga...@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?
>

I agree on this example.

Benedikt


>
> -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
>
>

Re: [text][lang] string escaping

Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 24, 2016 at 11:31 AM, Rob Tompkins <ch...@gmail.com> wrote:

>
> > On Nov 24, 2016, at 1:58 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > I just found that longestCommonPrefix does not exist in [lang]... let's
> > sort through what we have first before we imagine ourselves more
> headaches
> > ;-)
> >
>
> Fair, I more meant to pose an interesting example of where I think the
> boundary between text and lang is, and I’m completely with you that it
> seems squarely on the boundary.
>
> With that in mind, what are the thoughts on the original question now that
> we’ve explored where we think the boundary is? On one hand the mechanics
> behind string escaping seem to lie completely in text, but on the other the
> use case of it seem to lie more in lang.
>

For me, String escaping belongs in text because the content domain of the
strings are HTML, XML, JSON and other types of documents. These types of
documents are "text" and I would not expect HTML, JSON, and XML to belong
in java.lang and java.util. It's way above that.

Gary


> Cheers,
> -Rob
>
> > Gary
> >
> > On Thu, Nov 24, 2016 at 10:55 AM, Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Thu, Nov 24, 2016 at 5:54 AM, Rob Tompkins <ch...@gmail.com>
> wrote:
> >>
> >>>
> >>>> On Nov 22, 2016, at 4:38 PM, Gary Gregory <ga...@gmail.com>
> >>> wrote:
> >>>>
> >>>> On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <britter@apache.org
> >
> >>>> wrote:
> >>>>
> >>>>> Hello Gilles
> >>>>>
> >>>>> Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov.
> 2016
> >>>>>>> um
> >>>>>>> 19:09 Uhr:
> >>>>>>>
> >>>>>>>> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
> >>>>>>>> <br...@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hello Gray,
> >>>>>>>>>>>
> >>>>>>>>>>> Gary Gregory <ga...@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?
> >>>
> >>
> >> This is 50/50 in my mind because there is no "domain" like words,
> >> sentences, and so on. This is really about churning through a string for
> >> some condition.
> >>
> >> That said, moving it to [text] could be an opportunity to change the API
> >> name. Why is it longestCommonPrefix and not just commonPrefix? What
> would
> >> a shortestCommonPrefix is what I think when I see "longest".
> >>
> >> Gary
> >>
> >>
> >>>
> >>> -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&link
> >>> Code=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&link
> >>> Code=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4
> 18%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&link
> >>> Code=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Bli
> >>> nk_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
> >>>
> >>>
> >>
> >>
> >> --
> >> 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
> >>
> >
> >
> >
> > --
> > 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
>
>
> ---------------------------------------------------------------------
> 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

Re: [text][lang] string escaping

Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 24, 2016, at 1:58 PM, Gary Gregory <ga...@gmail.com> wrote:
> 
> I just found that longestCommonPrefix does not exist in [lang]... let's
> sort through what we have first before we imagine ourselves more headaches
> ;-)
> 

Fair, I more meant to pose an interesting example of where I think the boundary between text and lang is, and I’m completely with you that it seems squarely on the boundary.

With that in mind, what are the thoughts on the original question now that we’ve explored where we think the boundary is? On one hand the mechanics behind string escaping seem to lie completely in text, but on the other the use case of it seem to lie more in lang.

Cheers,
-Rob

> Gary
> 
> On Thu, Nov 24, 2016 at 10:55 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> 
>> 
>> 
>> On Thu, Nov 24, 2016 at 5:54 AM, Rob Tompkins <ch...@gmail.com> wrote:
>> 
>>> 
>>>> On Nov 22, 2016, at 4:38 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>> 
>>>> On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <br...@apache.org>
>>>> wrote:
>>>> 
>>>>> Hello Gilles
>>>>> 
>>>>> Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016
>>>>>>> um
>>>>>>> 19:09 Uhr:
>>>>>>> 
>>>>>>>> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
>>>>>>>> <br...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hello Gray,
>>>>>>>>>>> 
>>>>>>>>>>> Gary Gregory <ga...@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?
>>> 
>> 
>> This is 50/50 in my mind because there is no "domain" like words,
>> sentences, and so on. This is really about churning through a string for
>> some condition.
>> 
>> That said, moving it to [text] could be an opportunity to change the API
>> name. Why is it longestCommonPrefix and not just commonPrefix? What would
>> a shortestCommonPrefix is what I think when I see "longest".
>> 
>> Gary
>> 
>> 
>>> 
>>> -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&link
>>> Code=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&link
>>> Code=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&link
>>> Code=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Bli
>>> nk_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
>>> 
>>> 
>> 
>> 
>> --
>> 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
>> 
> 
> 
> 
> -- 
> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [text][lang] string escaping

Posted by Gary Gregory <ga...@gmail.com>.
I just found that longestCommonPrefix does not exist in [lang]... let's
sort through what we have first before we imagine ourselves more headaches
;-)

Gary

On Thu, Nov 24, 2016 at 10:55 AM, Gary Gregory <ga...@gmail.com>
wrote:

>
>
> On Thu, Nov 24, 2016 at 5:54 AM, Rob Tompkins <ch...@gmail.com> wrote:
>
>>
>> > On Nov 22, 2016, at 4:38 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <br...@apache.org>
>> > wrote:
>> >
>> >> Hello Gilles
>> >>
>> >> Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016
>> >>>> um
>> >>>> 19:09 Uhr:
>> >>>>
>> >>>>> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
>> >>>>> <br...@apache.org>
>> >>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Hello Gray,
>> >>>>>>>>
>> >>>>>>>> Gary Gregory <ga...@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?
>>
>
> This is 50/50 in my mind because there is no "domain" like words,
> sentences, and so on. This is really about churning through a string for
> some condition.
>
> That said, moving it to [text] could be an opportunity to change the API
> name. Why is it longestCommonPrefix and not just commonPrefix? What would
> a shortestCommonPrefix is what I think when I see "longest".
>
> Gary
>
>
>>
>> -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&link
>> Code=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&link
>> Code=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&link
>> Code=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Bli
>> nk_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
>>
>>
>
>
> --
> 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
>



-- 
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

Re: [text][lang] string escaping

Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 24, 2016 at 5:54 AM, Rob Tompkins <ch...@gmail.com> wrote:

>
> > On Nov 22, 2016, at 4:38 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> >> Hello Gilles
> >>
> >> Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016
> >>>> um
> >>>> 19:09 Uhr:
> >>>>
> >>>>> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
> >>>>> <br...@apache.org>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Hello Gray,
> >>>>>>>>
> >>>>>>>> Gary Gregory <ga...@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?
>

This is 50/50 in my mind because there is no "domain" like words,
sentences, and so on. This is really about churning through a string for
some condition.

That said, moving it to [text] could be an opportunity to change the API
name. Why is it longestCommonPrefix and not just commonPrefix? What would a
shortestCommonPrefix is what I think when I see "longest".

Gary


>
> -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
>
>


-- 
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

Re: [text][lang] string escaping

Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 22, 2016, at 4:38 PM, Gary Gregory <ga...@gmail.com> wrote:
> 
> On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <br...@apache.org>
> wrote:
> 
>> Hello Gilles
>> 
>> Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016
>>>> um
>>>> 19:09 Uhr:
>>>> 
>>>>> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
>>>>> <br...@apache.org>
>>>>> wrote:
>>>>>>> 
>>>>>>>> Hello Gray,
>>>>>>>> 
>>>>>>>> Gary Gregory <ga...@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


Re: [text][lang] string escaping

Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <br...@apache.org>
wrote:

> Hello Gilles
>
> Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016
> > > um
> > > 19:09 Uhr:
> > >
> > >> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
> > >> <br...@apache.org>
> > >> wrote:
> > >> >>
> > >> >>> Hello Gray,
> > >> >>>
> > >> >>> Gary Gregory <ga...@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.

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

Re: [text][lang] string escaping

Posted by Benedikt Ritter <br...@apache.org>.
Hello Gilles

Gilles <gi...@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 <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016
> > um
> > 19:09 Uhr:
> >
> >> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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
> >> <br...@apache.org>
> >> wrote:
> >> >>
> >> >>> Hello Gray,
> >> >>>
> >> >>> Gary Gregory <ga...@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
>
>

Re: [text][lang] string escaping

Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 22 Nov 2016 19:40:30 +0000, Benedikt Ritter wrote:
> Gary Gregory <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016 
> um
> 19:09 Uhr:
>
>> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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 
>> <br...@apache.org>
>> wrote:
>> >>
>> >>> Hello Gray,
>> >>>
>> >>> Gary Gregory <ga...@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".

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


Re: [text][lang] string escaping

Posted by Benedikt Ritter <br...@apache.org>.
Gary Gregory <ga...@gmail.com> schrieb am Sa., 19. Nov. 2016 um
19:09 Uhr:

> On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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 <br...@apache.org>
> wrote:
> >>
> >>> Hello Gray,
> >>>
> >>> Gary Gregory <ga...@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
> >
>

Re: [text][lang] string escaping

Posted by Gary Gregory <ga...@gmail.com>.
On Nov 19, 2016 9:50 AM, "Gilles" <gi...@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 <br...@apache.org>
wrote:
>>
>>> Hello Gray,
>>>
>>> Gary Gregory <ga...@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
>

Re: [text][lang] string escaping

Posted by Gilles <gi...@harfang.homelinux.org>.
On Sat, 19 Nov 2016 08:59:50 -0800, Gary Gregory wrote:
> On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter <br...@apache.org> 
> wrote:
>
>> Hello Gray,
>>
>> Gary Gregory <ga...@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.]

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


Re: [text][lang] string escaping

Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter <br...@apache.org> wrote:

> Hello Gray,
>
> Gary Gregory <ga...@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 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.

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.

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.

Thank you,
Gary



> Benedikt
>
>
> >
> > Gary
> >
> > --
> > 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
> >
>



-- 
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

Re: [text][lang] string escaping

Posted by Duncan Jones <du...@wortharead.com>.

> On 19 Nov 2016, at 15:38, Rob Tompkins <ch...@gmail.com> wrote:
> 
> 
>> On Nov 19, 2016, at 6:33 AM, Benedikt Ritter <br...@apache.org> wrote:
>> 
>> Hello Gray,
>> 
>> Gary Gregory <ga...@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.
> 
> I think this is a difficult distinction to draw because fundamentally anything that does sufficient text processing necessarily operates on a character by character basis. I propose below a distinction more along the lines of potential usage.
> 
>> 
>> 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?
> 
> I definitely agree with the sentiment that we should find a clear line of distinction between lang and text with regards to strings. Some thoughts that spring to mind are more in the terms of how the algorithms are to be used. 
> 
> So let’s consider the two extremes of the spectrum of string/word/text algorithms. On one hand, we have utilities like “StringUtils.isBlank(String s)” which is ubiquitously used in standard day to day and is a foundational extension of java. On the other hand, we have algorithms like natural language processing or statistical processing of words for analysis of biological sequences (two chapters in M. Lothaire’s “Applied Combinatorics on Words). The extremes seem to point towards day-to-day usage in any variety of java applications, where as the other extreme seems to point to an application that is specifically designed at string/word/text processing. I don’t see folks in everyday usage wanting to find edit distance between two strings unless they’re writing something specifically doing text processing or something of that nature.
> 
> Now clearly the problem with this distinction is the amount of grey area that it leaves in figuring out what goes where, so I don’t know if it’s the right way to go. It was just the thought that came to mind.
> 
> Any thoughts out there?

I think you're on the right track here. Lang is supposed to plug the gaps in Java's core packages. A certain amount of text manipulation is expected in many applications, but once we get into the realms of statistical analysis or fuzzy comparison methods then we've moved beyond that. 

Perhaps a tongue-in-cheek definition of "if you had to consult a book to write that, it belongs in Text". 

Duncan

> 
> Cheers,
> -Rob
> 
>> 
>> Benedikt
>> 
>> 
>>> 
>>> Gary
>>> 
>>> --
>>> 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
>>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [text][lang] string escaping

Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 19, 2016, at 6:33 AM, Benedikt Ritter <br...@apache.org> wrote:
> 
> Hello Gray,
> 
> Gary Gregory <ga...@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.

I think this is a difficult distinction to draw because fundamentally anything that does sufficient text processing necessarily operates on a character by character basis. I propose below a distinction more along the lines of potential usage.

> 
> 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?

I definitely agree with the sentiment that we should find a clear line of distinction between lang and text with regards to strings. Some thoughts that spring to mind are more in the terms of how the algorithms are to be used. 

So let’s consider the two extremes of the spectrum of string/word/text algorithms. On one hand, we have utilities like “StringUtils.isBlank(String s)” which is ubiquitously used in standard day to day and is a foundational extension of java. On the other hand, we have algorithms like natural language processing or statistical processing of words for analysis of biological sequences (two chapters in M. Lothaire’s “Applied Combinatorics on Words). The extremes seem to point towards day-to-day usage in any variety of java applications, where as the other extreme seems to point to an application that is specifically designed at string/word/text processing. I don’t see folks in everyday usage wanting to find edit distance between two strings unless they’re writing something specifically doing text processing or something of that nature.

Now clearly the problem with this distinction is the amount of grey area that it leaves in figuring out what goes where, so I don’t know if it’s the right way to go. It was just the thought that came to mind.

Any thoughts out there?

Cheers,
-Rob

> 
> Benedikt
> 
> 
>> 
>> Gary
>> 
>> --
>> 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
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [text][lang] string escaping

Posted by Benedikt Ritter <br...@apache.org>.
Hello Gray,

Gary Gregory <ga...@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?

Benedikt


>
> Gary
>
> --
> 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
>