Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Wed, 16 Jul 2003 16:05:07 -0400 (EDT)
From: Henri Yandell <bayard@generationjava.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri
 ngsa with somespaces
In-Reply-To: <004401c34b71$c6e219c0$693a29d9@oemcomputer>
Message-ID: <Pine.LNX.4.44.0307161604580.3543-100000@umbongo.flamefew.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


+1 to Stephen's plans btw for StringUtils.

Hen

On Wed, 16 Jul 2003, Stephen Colebourne wrote:

> From: "Gary Gregory" <ggregory@seagullsw.com>
> > I am not fond of isEmptyTrimmed, -1.
> The semantics of trim() are very specific, and different to other
> StringUtils methods (it removes all chars <= 32). Hence the method name must
> include the word trim.
>
>
> > Personally, I do not want to write code all over the place that reads
> >
> > if (StringUtils.isEmptyTrimmedOrNull(value)) {
> >
> > When I would be happy with a more *intelligent* isEmpty().
> >
> > if (StringUtils.isEmpty(value)) {
> My preference would also be for more intelligence, however I think we have
> to recognise that StringUtils needs to be usable quickly without constant
> javadoc reference. And that means explicit method names in certain cases.
>
> The new behaviour will also be consistent with the isAlpha() etc. methods
> where null is false.
>
>
> > At the risk my being dense (I can do that), can someone clarify why it is
> > important to test a trim String vs a /not/ trim'ed String? IOW, when would
> > it be incorrect for an app to do something when a value is "" but correct
> > when it is " " or "\t"?
> Who knows? Its really just the case that users have different requirements.
> We have already had one claim that null is treated differently from "" in an
> application. Same for spaces I guess.
>
> Stephen
>
>
> > Thanks,
> > Gary
> >
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Tuesday, July 15, 2003 17:12
> > 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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org