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 Tue, 15 Jul 2003 23:04:54 GMT
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


Mime
View raw message