Re: [lang] Proposal (2): isEmpty - commits

[Stephen Colebourne <sc...@btopenworld.com>]

I have updated CVS HEAD as follows:

Removed:
isEmptyOrNull
isNotEmptyOrNull
isEmptyTrimmed
isNotEmptyTrimmed
isEmptyTrimmedOrNull
isNotEmptyTrimmedOrNull

Changed:
isEmpty - true for "" or null
isNotEmpty - opposite (no change from 1.0)

Added:
isBlank - true for all whitespace, "" or null
isNotBlank - opposite

I suggest that committers think if they want to -1 veto this change.

Stephen

----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, July 19, 2003 9:54 PM
Subject: Re: [lang] Proposal (2): isEmpty


>
> So what's our 2.0 state with regard to this? What needs to be changed?
>
> Do we want to release tight with the following removed from current HEAD:
>
> isEmptyOrNull
> isNotEmptyOrNull
> isEmptyTrimmed
> isNotEmptyTrimmed
> isEmptyTrimmedOrNull
> isNotEmptyTrimmedOrNull
>
> Hen
>
> On Sat, 19 Jul 2003, Stephen Colebourne wrote:
>
> > From: "Henri Yandell" <ba...@generationjava.com>
> > > > It isn't. My preference is now for
> > > >
> > > > isEmpty() - "" or null
> > > > isBlank() - whitespace only, "" or null
> > >
> > > Could just tell people to do isWhitespace && isEmpty  ? :)
> >
> > I feel  isBlank() is more expressive than  isWhitespace(). It just feels
> > more inclusive of null and empty.
> >
> > if (isNotBlank()) {
> >   ...process data
> > }
> > OR
> > if (isNotWhitespace()) {
> >   ...process data
> > }
> >
> > Then again isWhitespace follows our naming definitions.
> >
> > ---
> > > > isEmptyTrimmed() - trim() then "" or null
> > >
> > > I'm not sure there's any need for this. I wonder how much of the chars
> > > less than 32 count as whitespace? But it seems that isWhitespace is
for
> > > most people's usage a superset of isEmptyTrimmed.
> >
> > Yeh, I'm happy to miss it out.
> >
> > ---
> > > > (plus isNotEmpty, isNotBlank, isEmptyNN, isBlankNN)
> > >
> > > Still hard to decide how far to go with all these. isEmptyNN is a
> > > single-atom method. isNotEmpty just replaces a ! sign etc etc.
> >
> > The Nots are very useful for these cases as they are so frequent.
> >
> > ---
> > > Does anyone actually want isEmptyNN, or is it just that people are
unhappy
> > > with the null-handling in StringUtils? In which case I think the NN is
the
> > > wrong solution, we need to be thinking about an ability to create a
> > > StringUtils with a strategy or having an underlying hidden class and 3
> > > facade's for the different strategies. All 3.0.
> >
> > +1. Leave out NN for now. Its a bit of a hack.
> >
> > Stephen
> >
> >
> > ---------------------------------------------------------------------
> > 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