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