Hello Rob,
Rob Tompkins <chtom...@gmail.com> schrieb am Do., 24. Nov. 2016 um
14:55 Uhr:
>
> > On Nov 22, 2016, at 4:38 PM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> >
> > On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter <brit...@apache.org>
> > wrote:
> >
> >> Hello Gilles
> >>
> >> Gilles <gil...@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 <garydgreg...@gmail.com> schrieb am Sa., 19. Nov. 2016
> >>>> um
> >>>> 19:09 Uhr:
> >>>>
> >>>>> On Nov 19, 2016 9:50 AM, "Gilles" <gil...@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
> >>>>> <brit...@apache.org>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Hello Gray,
> >>>>>>>>
> >>>>>>>> Gary Gregory <garydgreg...@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-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@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
>
>
