commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Caswell" <st...@mungoknotwise.com>
Subject RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
Date Wed, 16 Jul 2003 01:00:34 GMT
Given the ambiguity with terms we're dealing with, I think this proposal is
reasonable. And I don't mind having the *not* methods. I'll register my +1.


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: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Tuesday, July 15, 2003 7:12 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(), 
> isNotEmpty() and stri ngsa with somespaces
> 
> 
> 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
> 
> 
> 
> 



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