commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <Matthew.H...@capitalone.com>
Subject RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
Date Tue, 15 Jul 2003 17:56:46 GMT
I see no reason for any of the methods we are talking about to distinguish "
x " from "xyz" so lets simplify the set:

I always use Empty to refer to "" never null - I am unaware of anyone doing
any different.
I normally use Whitespace to mean " " etc but NOT "". I am aware some people
differ in this.
I am aware of many people using Blank to mean Empty OR Whitespace...but
could not vouch for it being a semi-formal convention.
Null means null :¬)

: indicates returns true for these entries 
"  " any amount of whitespace > 0

isEmpty() : ""
isEmptyOrNull() : "", null
isWhitespace(): "  "
isWhitespaceOrNull(): "  ", null

isBlank() : "", "  "
isBlankOrNull() : "", "  ", null
or
isEmptyOrWhitespace() : "", "  "
isEmptyOrWhitespaceOrNull() : "", "  ", null

verbose methods I admit but completely interpretation free. make negated
method naming extremely verbose (though still grammatically coreect with
regards the logic)...

isNotEmpty()
isNeitherEmptyNorNull()
isNotWhitespace()
isNeitherWhitespaceNorNull()

isNotBlank()
isNeitherBlankNorNull()
or
isNeitherEmptyNorWhitespace()
isNeitherEmptyNorWhitespaceNorNull()

If people think this is a ludicrously cumbersome api I fully understand, I
can't see any other solution without introducing new (inevitablly)
non-standard terms.

Matt

> -----Original Message-----
> From: Todd Jonker [mailto:tvj@pobox.com] 
> Sent: 15 July 2003 18:20
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(), 
> isNotEmpty() and stri ngsa with somespaces
> 
> 
> Hi Stephen, thanks for your comments.
> 
> I created definitions because the current system seems to 
> have no consistent
> definitions, and the one that started the thread, "empty", is 
> being used in
> a manner contrary (IMO) to the accepted usage.  So I tried to 
> come up with a
> system that used terms in a consistent and well-defined 
> manner, and covers
> all of the "interesting" cases.
> 
> The notion of 'is "" but not null'  is used quite a bit in 
> code I write.  A
> null string is a very different beast than a zero-length 
> string.  I have it
> in my own library, but I'd rather get rid of my code and use commons.
> 
> I don't have a problem defining isEmpty to mean (null || "")  as you
> implemented, but for my uses there are methods missing, and 
> the handling of
> null seemed a bit disjointed.  Recognizing that, I tried to 
> come up with a
> set from scratch that meets my needs and has simple 
> terminology.  True,
> there are some new terms, but I think they are easy to learn.  YMMV.
> 
> .T.
> 
> 
> On 7/15/03 12:46 PM, scolebourne@btopenworld.com wrote:
> 
> > Actually, thats the problem with the proposal. Lots of definitions.
> 
> 
> > 
> > Following the recent change, Empty means "" (across various 
> methods). In
> > addition, the isEmpty() method handles null sensibly. Thats all.
> > 
> > isEmptyTrimmed() is explicit that it uses trim(). Which is good.
> > 
> > Do we need a method 'is "" but not null'? Doesn't make sense to me.
> > 
> > I'll have another look tonight to see if we could use the 
> term Blank usefully.
> > 
> > Stephen
> > 
> >>  from:    Gary Gregory <ggregory@seagullsw.com>
> >> 
> >> 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
> > 
> > 
> > 
> 
> -- 
> 
> A patriot must always be ready to defend his country against its
> government.  -Edward Abbey, naturalist and author (1927-1989)
> 
>     Defend our country!  Vote Howard Dean 2004
>         http://www.DeanForAmerica.com/
>         http://www.MoveOn.org/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

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