Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 60356 invoked from network); 16 Jul 2003 01:00:32 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 16 Jul 2003 01:00:32 -0000 Received: (qmail 23665 invoked by uid 97); 16 Jul 2003 01:03:09 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@nagoya.betaversion.org Received: (qmail 23657 invoked from network); 16 Jul 2003 01:03:08 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 16 Jul 2003 01:03:08 -0000 Received: (qmail 60100 invoked by uid 500); 16 Jul 2003 01:00:29 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 60088 invoked from network); 16 Jul 2003 01:00:29 -0000 Received: from imf21aec.mail.bellsouth.net (HELO imf21aec.bellsouth.net) (205.152.59.69) by daedalus.apache.org with SMTP; 16 Jul 2003 01:00:29 -0000 Received: from YellowJacket ([68.211.115.111]) by imf21aec.bellsouth.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030716010037.DFHX16013.imf21aec.bellsouth.net@YellowJacket> for ; Tue, 15 Jul 2003 21:00:37 -0400 Reply-To: From: "Steven Caswell" To: "'Jakarta Commons Developers List'" Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces Date: Tue, 15 Jul 2003 21:00:34 -0400 Message-ID: <002301c34b35$a97e6a50$6f00a8c0@YellowJacket> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <007e01c34b2e$e3da01c0$724729d9@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 - null empty - a zero-length > string ("") space - the space character (

' 
> '

)(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" > To: "'Jakarta Commons Developers List'" > > 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 > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > >> > > > > >>>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 > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > >------------------------------------------------------------------- > > > >-- > > > > >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