commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
Date Wed, 16 Jul 2003 00:12:03 GMT
OK, time to summarise the debate a little.

I have examined Java's String and StringBuffer classes. These refer to
'empty' as "". They make no reference to 'blank'.

As a result I have updated StringUtils using the following terminology:
null - <code>null</code>
empty - a zero-length string (<code>""</code>)
space - the space character (<code>' '</code>)(32)
whitespace - the characters defined by {@link Character#isWhitespace(char)}

All references to 'blank' have been removed. (Note that I've only gone
through StringUtils, not other classes).

This now means that the currently coded method isEmpty() is wrong as it
returns true for null. Similarly for isNotEmpty().

Thus I propose:
isEmpty(), true for "", false for null
isEmptyOrNull(), true for "" and null
isEmptyTrimmed(), trim() then true for "", false for null
isEmptyTrimmedOrNull(), trim() then true for "", true for null

(Other proposed methods can be considered after 2.0. These should be
considered now)

I also propose the negative methods are the exact opposite.
isNotEmpty()
isNotEmptyOrNull()
isNotEmptyTrimmed()
isNotEmptyTrimmedOrNull()

For deprecation issues see another thread.

Can we have a +1 or not for this proposal.

Stephen

----- Original Message -----
From: "Steven Caswell" <steve@mungoknotwise.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Sent: Wednesday, July 16, 2003 12:04 AM
Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri
ngsa with somespaces


> I agree with Henri that a major benefit of the current isEmpty() is the
> silent null handling. I would not be opposed to changing it to not trim,
as
> long as there was an equivalent isEmptyTrimmed(), but I'm against removing
> the silent null handling. If I remember correctly, that was the original
> intent.
>
> I'm also very leery of a major change to the functionality of existing
> methods. For backward compatibility, which I believe is very important, I
> hope we can come up with different names and leave the existing methods
> pretty much as is.
>
> And I also agree that Trivial just doesn't float my boat.
>
> Steven Caswell
> steve@mungoknotwise.com
> a.k.a Mungo Knotwise of Michel Delving
> "One ring to rule them all, one ring to find them..."
>
>
> > -----Original Message-----
> > From: Henri Yandell [mailto:bayard@generationjava.com]
> > Sent: Tuesday, July 15, 2003 3:20 PM
> > To: Jakarta Commons Developers List
> > Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(),
> > isNotEmpty() and stri ngsa with somespaces
> >
> >
> >
> > The only major input I have at the moment is -1 to Trivial.
> > It's hard to find good words, but trivial just doesn't fit.
> >
> > The number one piece of code to support is:
> >
> >   if( foo.getParameter() != null && !"".equals(foo.getParameter()) ) {
> >
> > into
> >
> >   if( !StringUtils.isEmpty(foo.getParameter()) {
> >
> > It reads a lot more easily, and is something that you quite
> > often find yourself doing in crappy ServletRequest-style environments.
> >
> > Having the trims/not's is just syntactic sugar. I'm not a big
> > fan of the trim, and like the 'Trimmed' method to show it is there.
> >
> > I do however like having systems that behave quietly when
> > possible under null. Throwing an NPE because null is just
> > utterly illegal is cool, such as a substring() method that's
> > meant to return an int, but for a boolean I quite like
> > returning false in the null case.
> >
> > If an object was meant to be returned, I believe null should
> > be returned.
> > ie) replace(null, "g", "q") would return null. However
> > passing null into one of the latter arguments may throw an
> > IllegalArgumentException. Or NPE. Whichever standard we end up on.
> >
> > Hen
> >
> >
> > On Tue, 15 Jul 2003, Gary Gregory wrote:
> >
> > > Can we come up with a better name than "isTrivial"?
> > >
> > > if (StringUtils.isTrivial(hello)) {
> > > }
> > >
> > > I still can't recall what that does! ;-)
> > >
> > > Gary
> > >
> > > -----Original Message-----
> > > From: __matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu]
> > > Sent: Tuesday, July 15, 2003 08:26
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(),
> > isNotEmpty() and
> > > stri ngsa with somespaces
> > >
> > > I agree that having both is/isNot methods is convenient, but I also
> > > find it slightly confusing, and it adds more code to maintain.
> > >
> > > However, as long as they conform to the standard of:
> > >
> > > boolean isNotEmpty(String s) {
> > >     return !isEmpty(s);
> > > }
> > >
> > > it will at least keep the code easily maintainable.
> > >
> > > Thoughts?
> > >
> > >
> > >
> > >
> > > Todd Jonker wrote:
> > >
> > > >Matt, thanks for your comments.
> > > >
> > > >I guess you're right, we should probably add all of the negated
> > > >calls:
> > > >
> > > >    isEmpty           isNotEmpty
> > > >    isWhitespace      isNotWhitespace
> > > >    isTrivial         isNotTrivial
> > > >    isBlank           isNotBlank
> > > >
> > > >This morning I'm feeling like they should all be
> > "isNotSomething" for
> > > >the sake of uniformity with most other code.  At least
> > there's only
> > > >one that's incorrect English (to my ears, at leas).
> > > >
> > > >I certainly don't object to the negated methods, it's just that I
> > > >tend to prefer the streamlined API.
> > > >
> > > >..T.
> > > >
> > > >
> > > >On 7/15/03 4:34 AM, Matthew.Hope@capitalone.com wrote:
> > > >
> > > >
> > > >
> > > >>As a user I agree with the benefits of both proposals
> > (can't decide
> > > >>which
> > > I
> > > >>prefer yet). When I saw the initial proposal I wasn't
> > happy either
> > > >>but
> > > could
> > > >>not come up with a 'complete' solution either.
> > > >>
> > > >>one point on the first though, I would find in my code
> > that the vast
> > > >>majority of my use cases would be
> > > >>
> > > >>if (! isTrivial(s)) {
> > > >>// do something that assumes a non null / length() > 0 string }
> > > >>
> > > >>I dislike overuse of (! someMethod()), especially since I started
> > > >>doing
> > > code
> > > >>maintenace with the help of back browse facilities which
> > find method
> > > >>usage (rather than more fallible regexp). I would therefore like
> > > >>isNonTrivial(s) to be provided.
> > > >>
> > > >>Matt
> > > >>
> > > >>
> > > >>
> > > >>>-----Original Message-----
> > > >>>From: Todd Jonker [mailto:tvj@pobox.com]
> > > >>>Sent: 15 July 2003 02:39
> > > >>>To: hen@umbongo.flamefew.net; commons-dev@jakarta.apache.org
> > > >>>Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(),
> > > >>>isNotEmpty() and stringsa with somespaces
> > > >>>
> > > >>>
> > > >><snip>
> > > >>
> > > >>
> > > >>>I tend to dislike thinks like isNotBlank since it increases the
> > > >>>number of methods one needs to wade through, but adds no new
> > > >>>semantic expressiveness.
> > > >>>Also, the methods above would lead to isNotTrivial, where
> > > >>>isNonTrivial is much more natural
> > > >>>
> > > >>>
> > > >><snip>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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


Mime
View raw message