commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692)
Date Wed, 07 Jul 2004 05:10:49 GMT

+1.

Tokens is definitely the noun to use (took a while for me to get that a
String to be split is made up of separators and tokens). While we could
have splitPreservingEmptyTokens or something, splitPreservingTokens or
splitPreserveTokens seem fine.

Unsure if the verb should be current or past.

Hen


(Btw, have added the desire not to use booleans to overload methods with
same signature to DEV guide)

On Tue, 6 Jul 2004, Michael Heuer wrote:

>
> How about 'splitPreserveTokens' ?
>
>    michael
>
>
> On Tue, 6 Jul 2004, Gary Gregory wrote:
>
> > <ed>I am not making a big stink about this. My belief is that names are
> > important, especially in a library. I like to discuss such things.</ed>
> >
> > Just to be more precise, what I am not fond of in "splitVerb", as in
> > "splitPreserve", is that *what* is to be preserved is not specified and
> > in my IMO not obvious, which is why I prefer, in the replacement of a
> > boolean method (about which I am neutral), "splitVerbObject", as in
> > maybe "splitKeepAllTokens". When I read code and I see
> > splitKeepAllTokens (or something like it) I can pretty much guess (I
> > think) what is going to happen.
> >
> > Now, you guys can tell that it is 100% obvious that the name
> > "splitPreserve" describes an API that preserves all of the tokens (after
> > all what else is there to preserve I wonder, but I do not have to wonder
> > if you tell me in the name), in which case I'll happily believe you. My
> > preference is too err on the side of verbosity and non-mysterious API
> > names vs. brevity ;-) The C days are long gone :-)
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Steven Caswell [mailto:steve@mungoknotwise.com]
> > > Sent: Tuesday, July 06, 2004 16:51
> > > To: 'Jakarta Commons Developers List'
> > > Subject: RE: [lang] StringUtils.split ignores empty items (Bugzilla
> > bug#
> > > 22692)
> > >
> > > Gary didn't like splitPreserve. I originally suggested splitPreserve
> > so
> > > that's fine by me. I could also go with splitAll.
> > >
> > > And I agree, I don't like the boolean flags either.
> > >
> > >
> > > Steven Caswell
> > > Sun Certified Java Programmer
> > > steve@mungoknotwise.com
> > > "War is an ugly thing, but not the ugliest of things. The decayed and
> > > degraded state of moral and patriotic feeling that thinks that nothing
> > is
> > > worth war is much worse. The person who has nothing for which he is
> > > willing
> > > to fight, nothing which is more important than his own personal
> > safety, is
> > > a
> > > miserable creature and has no chance of being free unless made and
> > kept so
> > > by the exertions of better men than himself." .... John Stuart Mill.
> > >
> > >
> > > > -----Original Message-----
> > > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > > Sent: Tuesday, July 06, 2004 6:28 PM
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [lang] StringUtils.split ignores empty items
> > > > (Bugzilla bug# 22692)
> > > >
> > > >
> > > > StringUtils currently has no boolean flags in method args,
> > > > and I want to keep it that way.
> > > >
> > > > splitAll?
> > > > 'Split the string keeping All the tokens'
> > > >
> > > > splitPreserve?
> > > > 'Split the string Preserving all the tokens'
> > > >
> > > > Stephen
> > > >
> > > > ----- Original Message -----
> > > > From: "Steven Caswell" <steve@mungoknotwise.com>
> > > > I agree the name is not great. I'm not sure the other
> > > > suggestions convey the method behavior either. I typically
> > > > don't like adding a boolean to change the behavior, but
> > > > rather have a different method of similar name, but I can't
> > > > think of a great name either.
> > > >
> > > > A few more suggestions:
> > > > - splitIncludeEmptyTokens
> > > > - splitKeepEmptyTokens
> > > > - splitWithEmptyTokens
> > > >
> > > > I think I like splitIncludeEmptyTokens the best. But to not
> > > > keep beating this one to death, if one of these is not
> > > > suitable, let's just go with adding a boolean argument.
> > > >
> > > > Steven Caswell
> > > > Sun Certified Java Programmer
> > > > steve@mungoknotwise.com
> > > > "War is an ugly thing, but not the ugliest of things. The
> > > > decayed and degraded state of moral and patriotic feeling
> > > > that thinks that nothing is worth war is much worse. The
> > > > person who has nothing for which he is willing to fight,
> > > > nothing which is more important than his own personal safety,
> > > > is a miserable creature and has no chance of being free
> > > > unless made and kept so by the exertions of better men than
> > > > himself." .... John Stuart Mill.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Gary Gregory [mailto:ggregory@seagullsoftware.com]
> > > > > Sent: Tuesday, July 06, 2004 12:45 PM
> > > > > To: Jakarta Commons Developers List
> > > > > Subject: RE: [lang] StringUtils.split ignores empty items
> > (Bugzilla
> > > > > bug# 22692)
> > > > >
> > > > >
> > > > > Indeed not a great name. "splitPreserve" does not tell you
> > > > what it is
> > > > > preserving. How about:
> > > > >
> > > > > - Instead of splitPreserve, split with boolean argument.
> > > > > - Use another word: "Keep" or "Include" or "With", with or without
> > > > > "what" is preserved:
> > > > > - splitKeep
> > > > > - splitKeepSeparator
> > > > > - splitWith
> > > > > - splitWithSeparator
> > > > > - splitInclude
> > > > > - splitIncludeSeparator
> > > > >
> > > > > ?
> > > > >
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > > > > Sent: Monday, July 05, 2004 15:43
> > > > > > To: Jakarta Commons Developers List
> > > > > > Subject: Re: [lang] StringUtils.split ignores empty items
> > > > (Bugzilla
> > > > > bug#
> > > > > > 22692)
> > > > > >
> > > > > > Although splitPreserve isn't a great name, I can't thinkn
> > > > > of a better
> > > > > one.
> > > > > > This does seem to be requested functionality for a utils class
> > in
> > > > > addition
> > > > > > to Tokenizer, so +1.
> > > > > >
> > > > > > Stephen
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Steven Caswell" <steve@mungoknotwise.com>
> > > > > > Regarding the solution for
> > > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=22692,
> > > > in addition
> > > > > to
> > > > > > the
> > > > > > fine work on the Tokenizer class, I'd like to address the
> > initial
> > > > > > complaint about how the split methods treat adjacent
> > > > > separators as one
> > > > > separator. I
> > > > > > agree with Juergen that adjacent separators should not be
> > > > > treated this
> > > > > > way, but should return an empty array element for adjacent
> > > > > separators.
> > > > > >
> > > > > > I propose to create an additional set of split methods that
> > would
> > > > > preserve
> > > > > > separators. To preserve backward compatibility, I propose
> > > > > it be called
> > > > > > splitPreserve to distinguish from the existing split method.
The
> > > > > > functionality would be:
> > > > > >
> > > > > > For an input string of "a:b:::d" the return array would be
> > > > > array[0] =
> > > > > > "a" array[1] = "b"
> > > > > > array[2] = ""
> > > > > > array[3] = ""
> > > > > > array[4] = "d"
> > > > > >
> > > > > >
> > > > > >
> > > > > > Steven Caswell
> > > > > > Sun Certified Java Programmer
> > > > > > steve@mungoknotwise.com
> > > > > > "War is an ugly thing, but not the ugliest of things. The
> > > > > decayed and
> > > > > > degraded state of moral and patriotic feeling that thinks
> > > > > that nothing
> > > > > is
> > > > > > worth war is much worse. The person who has nothing for
> > > > which he is
> > > > > > willing to fight, nothing which is more important than his own
> > > > > > personal
> > > > > safety, is
> > > > > > a
> > > > > > miserable creature and has no chance of being free unless made
> > and
> > > > > kept so
> > > > > > by the exertions of better men than himself." .... John
> > > > Stuart Mill.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > 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
>




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