So, there are no isWhitespace methods, right? Gray
-----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2003 14:58 To: Jakarta Commons Developers List Subject: Re: [lang] Proposal (2): isEmpty - commits 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" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
