[lang] Giant StringUtils vs. NullSafeStrings.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[lang] Giant StringUtils vs. NullSafeStrings.

garydgregory
Hi All:

Right now we have a giant class called StringUtils. I have code that in my
own library that has at least one null-safe API that for Strings. For
example a String.getBytes(String, Charset) that returns a null byte[] if
the input String is null.

I'd like to propose a new class called NullSafeStrings, that covers all
String APIs (there aren't that many) for null-safe String input. If some of
these APIs are already in StringUtils, those would be deprecated and point
to NullSafeStrings.

Note that I am not using the "Utils" postfix on purpose since I find it
meaning less and the JRE now uses the plural form for this kind of code;
see Files and Paths.

Thoughts?

Gary
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Giant StringUtils vs. NullSafeStrings.

Mark Dacek
I’m a bit curious on the desire to split it out. I’m not hard opposed but
also don’t know that it would save much time or clarify things for most. I
wouldn’t want to say that this is a critical reason for keeping things as
they are, but I’d imagine that your typical dev doesn’t use StringUtils for
abbreviate or getLevenshteinDistance style-features nearly as often as they
do for length and indexOf to avoid onerous unit tests.


On Tue, May 28, 2019 at 7:53 AM Gary Gregory <[hidden email]> wrote:

> Hi All:
>
> Right now we have a giant class called StringUtils. I have code that in my
> own library that has at least one null-safe API that for Strings. For
> example a String.getBytes(String, Charset) that returns a null byte[] if
> the input String is null.
>
> I'd like to propose a new class called NullSafeStrings, that covers all
> String APIs (there aren't that many) for null-safe String input. If some of
> these APIs are already in StringUtils, those would be deprecated and point
> to NullSafeStrings.
>
> Note that I am not using the "Utils" postfix on purpose since I find it
> meaning less and the JRE now uses the plural form for this kind of code;
> see Files and Paths.
>
> Thoughts?
>
> Gary
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Giant StringUtils vs. NullSafeStrings.

garydgregory
On Tue, May 28, 2019 at 5:04 PM Mark Dacek <[hidden email]> wrote:

> I’m a bit curious on the desire to split it out. I’m not hard opposed but
> also don’t know that it would save much time or clarify things for most. I
> wouldn’t want to say that this is a critical reason for keeping things as
> they are, but I’d imagine that your typical dev doesn’t use StringUtils for
> abbreviate or getLevenshteinDistance style-features nearly as often as they
> do for length and indexOf to avoid onerous unit tests.
>

The immediate motivation is that StringUtils does not have a null-safe
version of String#getBytes(String). It does have null-safe versions of a
_few_ methods from for Strings and CharSequences.

Instead of making StringUtils even larger and more unwieldy, I was thinking
that having class more focused on "I want to call String methods in a null
safe way" as opposed to "I want to perform non-JRE-standard operation on
Strings"

The obvious drawback is that you now have two classes to mine for
functionality instead of one, so typing StringUtils in your IDE will not
present the new methods in the NullSafeStrings, you'd have to remember/know
what belongs where; IOW you'd have to know what belongs in String vs. not.

It was just an idea. For now, I am happy to just add a null safe
String#getBytes(String) to StringUtils.

Gary



> On Tue, May 28, 2019 at 7:53 AM Gary Gregory <[hidden email]>
> wrote:
>
> > Hi All:
> >
> > Right now we have a giant class called StringUtils. I have code that in
> my
> > own library that has at least one null-safe API that for Strings. For
> > example a String.getBytes(String, Charset) that returns a null byte[] if
> > the input String is null.
> >
> > I'd like to propose a new class called NullSafeStrings, that covers all
> > String APIs (there aren't that many) for null-safe String input. If some
> of
> > these APIs are already in StringUtils, those would be deprecated and
> point
> > to NullSafeStrings.
> >
> > Note that I am not using the "Utils" postfix on purpose since I find it
> > meaning less and the JRE now uses the plural form for this kind of code;
> > see Files and Paths.
> >
> > Thoughts?
> >
> > Gary
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Giant StringUtils vs. NullSafeStrings.

garydgregory
On Wed, May 29, 2019 at 8:07 AM Gary Gregory <[hidden email]> wrote:

> On Tue, May 28, 2019 at 5:04 PM Mark Dacek <[hidden email]> wrote:
>
>> I’m a bit curious on the desire to split it out. I’m not hard opposed but
>> also don’t know that it would save much time or clarify things for most. I
>> wouldn’t want to say that this is a critical reason for keeping things as
>> they are, but I’d imagine that your typical dev doesn’t use StringUtils
>> for
>> abbreviate or getLevenshteinDistance style-features nearly as often as
>> they
>> do for length and indexOf to avoid onerous unit tests.
>>
>
> The immediate motivation is that StringUtils does not have a null-safe
> version of String#getBytes(String). It does have null-safe versions of a
> _few_ methods from for Strings and CharSequences.
>
> Instead of making StringUtils even larger and more unwieldy, I was
> thinking that having class more focused on "I want to call String methods
> in a null safe way" as opposed to "I want to perform non-JRE-standard
> operation on Strings"
>
> The obvious drawback is that you now have two classes to mine for
> functionality instead of one, so typing StringUtils in your IDE will not
> present the new methods in the NullSafeStrings, you'd have to remember/know
> what belongs where; IOW you'd have to know what belongs in String vs. not.
>
> It was just an idea. For now, I am happy to just add a null safe
> String#getBytes(String) to StringUtils.
>

Tracking with https://issues.apache.org/jira/browse/LANG-1461

Gary


>
> Gary
>
>
>
>> On Tue, May 28, 2019 at 7:53 AM Gary Gregory <[hidden email]>
>> wrote:
>>
>> > Hi All:
>> >
>> > Right now we have a giant class called StringUtils. I have code that in
>> my
>> > own library that has at least one null-safe API that for Strings. For
>> > example a String.getBytes(String, Charset) that returns a null byte[] if
>> > the input String is null.
>> >
>> > I'd like to propose a new class called NullSafeStrings, that covers all
>> > String APIs (there aren't that many) for null-safe String input. If
>> some of
>> > these APIs are already in StringUtils, those would be deprecated and
>> point
>> > to NullSafeStrings.
>> >
>> > Note that I am not using the "Utils" postfix on purpose since I find it
>> > meaning less and the JRE now uses the plural form for this kind of code;
>> > see Files and Paths.
>> >
>> > Thoughts?
>> >
>> > Gary
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Giant StringUtils vs. NullSafeStrings.

Emmanuel Bourg-3
In reply to this post by garydgregory
Le 28/05/2019 à 13:46, Gary Gregory a écrit :

> Thoughts?

Maybe we could make a more ambitious 'Strings' class with methods taken
from StringUtils and refactored with a fluent API to avoid the
combinatorial explosion of StringUtils? Just a wild idea.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Giant StringUtils vs. NullSafeStrings.

Xeno Amess
Then 10 years later JDK has its own Strings, and users get confused then.

Emmanuel Bourg <[hidden email]> 于2019年6月4日周二 下午6:58写道:

> Le 28/05/2019 à 13:46, Gary Gregory a écrit :
>
> > Thoughts?
>
> Maybe we could make a more ambitious 'Strings' class with methods taken
> from StringUtils and refactored with a fluent API to avoid the
> combinatorial explosion of StringUtils? Just a wild idea.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Giant StringUtils vs. NullSafeStrings.

Matt Sicker
The JDK is the only source allowed to modify java.lang.String, so
they'd likely add static methods to that directly like String.join()
and the others. The plural name thing was more of an issue with an
interface Thing and utility class Things. As of Java 8, there's
typically no need to have a Things class because the Thing interface
can have static methods on it. For example, see all the static methods
added to Comparator that would have typically gone into a class named
Comparators (like Collector/Collectors).

On Tue, 4 Jun 2019 at 06:07, Xeno Amess <[hidden email]> wrote:

>
> Then 10 years later JDK has its own Strings, and users get confused then.
>
> Emmanuel Bourg <[hidden email]> 于2019年6月4日周二 下午6:58写道:
>
> > Le 28/05/2019 à 13:46, Gary Gregory a écrit :
> >
> > > Thoughts?
> >
> > Maybe we could make a more ambitious 'Strings' class with methods taken
> > from StringUtils and refactored with a fluent API to avoid the
> > combinatorial explosion of StringUtils? Just a wild idea.
> >
> > Emmanuel Bourg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >



--
Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Giant StringUtils vs. NullSafeStrings.

Xeno Amess
As a fact that class jdk.internal.joptsimple.internal.Strings does
exist, I don't think we shall add a class named Strings.
That will be misleading sometimes.

Matt Sicker <[hidden email]> 于2019年6月5日周三 上午12:32写道:

>
> The JDK is the only source allowed to modify java.lang.String, so
> they'd likely add static methods to that directly like String.join()
> and the others. The plural name thing was more of an issue with an
> interface Thing and utility class Things. As of Java 8, there's
> typically no need to have a Things class because the Thing interface
> can have static methods on it. For example, see all the static methods
> added to Comparator that would have typically gone into a class named
> Comparators (like Collector/Collectors).
>
> On Tue, 4 Jun 2019 at 06:07, Xeno Amess <[hidden email]> wrote:
> >
> > Then 10 years later JDK has its own Strings, and users get confused then.
> >
> > Emmanuel Bourg <[hidden email]> 于2019年6月4日周二 下午6:58写道:
> >
> > > Le 28/05/2019 à 13:46, Gary Gregory a écrit :
> > >
> > > > Thoughts?
> > >
> > > Maybe we could make a more ambitious 'Strings' class with methods taken
> > > from StringUtils and refactored with a fluent API to avoid the
> > > combinatorial explosion of StringUtils? Just a wild idea.
> > >
> > > Emmanuel Bourg
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
>
>
> --
> Matt Sicker <[hidden email]>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Giant StringUtils vs. NullSafeStrings.

jochen-2
In reply to this post by Xeno Amess
On Tue, Jun 4, 2019 at 1:07 PM Xeno Amess <[hidden email]> wrote:
>
> Then 10 years later JDK has its own Strings, and users get confused then.

If we (and the users) wouldn't be ready to accept that risk, then we
could forget the whole project.

Jochen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]