commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
Date Thu, 17 Jul 2003 00:03:52 GMT
Changes made. Again a sanity check by someone would be good.

Hen, you might also want to re-run your diff for the release notes when we
are ready, as I'm sure its not completely accurate any more.

Stephen


----- Original Message -----
From: "Henri Yandell" <bayard@generationjava.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Wednesday, July 16, 2003 9:05 PM
Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri
ngsa with somespaces


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


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