commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <mhawtho...@alumni.pitt.edu>
Subject Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
Date Tue, 15 Jul 2003 18:17:16 GMT
Another option is to throw a NullPointer or IllegalArgument exception on 
any null inputs.  This would simplify the API and remove the need for a 
lot of these extra methods.  In my experience, handling null "nicely" 
leads to a lot of confusion, and usually results in errors being passed 
on to another place.  However, if the behavior is well documented it's 
not so much of a problem.

My point is, adding methods for isNot methods, and isXXXOrNull methods 
may be overkill.  StringUtils is a huge class, one possibility is to 
simplify the current methods, and then have some null-friendly, or 
negated wrappers avalable for it.




Hope, Matthew wrote:

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


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