commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [text][lang] string escaping
Date Tue, 22 Nov 2016 19:55:24 GMT
On Tue, 22 Nov 2016 19:40:30 +0000, Benedikt Ritter wrote:
> Gary Gregory <garydgregory@gmail.com> schrieb am Sa., 19. Nov. 2016 
> um
> 19:09 Uhr:
>
>> On Nov 19, 2016 9:50 AM, "Gilles" <gilles@harfang.homelinux.org> 
>> wrote:
>> >
>> > On Sat, 19 Nov 2016 08:59:50 -0800, Gary Gregory wrote:
>> >>
>> >> On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter 
>> <britter@apache.org>
>> wrote:
>> >>
>> >>> Hello Gray,
>> >>>
>> >>> Gary Gregory <garydgregory@gmail.com> schrieb am Sa., 19. Nov.

>> 2016 um
>> >>> 01:07 Uhr:
>> >>>
>> >>> > Just a thought:
>> >>> >
>> >>> > Does all the current (and future) string escaping code (XML, 
>> HTML,
>> ...)
>> >>> > really belong in [lang]? Would it be more natural to have it 
>> in
>> [text]?
>> >>> >
>> >>>
>> >>> My view on the whole think currently is, that we put stuff that 
>> is
>> related
>> >>> to strings in Lang. Code that works on texts should go to Text. 
>> To me a
>> >>> text is more than just a string. A text contains works, that 
>> make up
>> >>> sentences, which in turn build paragraphs.
>> >>>
>> >>> Using this description, I'd argue that escaping belongs into 
>> lang and
>> not
>> >>> into text, because it works on individual characters rather than 
>> on
>> texts.
>> >>>
>> >>> But this would also raise the question if the various edit 
>> distance
>> >>> algorithms works on texts or on strings. So maybe my distinction 
>> is not
>> >>> good at all.
>> >>>
>> >>> Do we need to better specify the scope of text?
>> >>>
>> >>
>> >> Great question of course.
>> >>
>> >> I'd like to think of [lang] as "What is missing from the JRE's 
>> most
>> basic
>> >> classes and specifically from the java.lang package and some 
>> java.util
>> >> classes".
>> >>
>> >> Quoting from our site:
>> >>
>> >> "The standard Java libraries fail to provide enough methods for
>> >> manipulation of its core classes. Apache Commons Lang provides 
>> these
>> extra
>> >> methods.
>> >> Lang provides a host of helper utilities for the java.lang API, 
>> notably
>> >> String manipulation methods, basic numerical methods, object 
>> reflection,
>> >> concurrency, creation and serialization and System properties.
>> Additionally
>> >> it contains basic enhancements to java.util.Date
>> >
>> >
>> > How about "Date" becoming a nice standalone component? ;-)
>> > [Components should be concept-based.]
>>
>> Joda-time covers more than we will ever do here IMO. And Java 8 has 
>> new
>> time APIs... maybe when lang is Java 8 based we can look again. For 
>> now I'd
>> rather leave dates as is.
>>
>
> Yes, let's get back to topic.
>
> I think we need a clear distinction between string related stuff that 
> goes
> into Lang and more complex stuff that goes into text.

IMHO "more complex" is key, not so much "string" vs "text".

Hence I suggest [text] is a better place for "RandomStringUtils"
than [lang], and the former should allow dependencies as a
foundation for that complexity; in that case, that would be
"Commons RNG".

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


Mime
View raw message