commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang] nIndexOf/ordinalIndexOf
Date Tue, 26 Aug 2003 17:55:53 GMT
Just for arg's sake:

1) ordinalIndexOf (String str, String searchStr, int ordinal)
2) indexOfOrdinal (String str, String searchStr, int ordinal)

Gary


> -----Original Message-----
> From: Arun Thomas [mailto:Arun.Thomas@solidusnetworks.com]
> Sent: Tuesday, August 26, 2003 10:02
> To: Jakarta Commons Developers List
> Subject: [lang] nIndexOf/ordinalIndexOf
> 
> I've got to say that I like the parallelism with the other methods.
> 
> For what it's worth, I like: ordinalIndexOf(String str, String searchStr,
> int ordinal)
> 
> -AMT
> 
> -----Original Message-----
> From: Gary Gregory [mailto:ggregory@seagullsw.com]
> Sent: Monday, August 25, 2003 11:27 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [VOTE] Release of Commons Lang 2.0 [take 2]
> 
> 
> Inline:
> 
> > -----Original Message-----
> > From: Phil Steitz [mailto:phil@steitz.com]
> > Sent: Monday, August 25, 2003 23:11
> > To: Jakarta Commons Developers List
> > Subject: Re: [VOTE] Release of Commons Lang 2.0 [take 2]
> >
> > Gary Gregory wrote:
> > > Ah, well, in that sprit, then comments on
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22719 would be
> > appreciated
> > > but I do not expect this to go in 2.0 unless other folks like/need
> > > it.
> >
> > Looks useful to me. I would go ahead and add it. Here are a couple of
> > small comments:
> >
> > 1. Yes, the name sucks, but nothing nice jumps out at me. Of the
> > alternatives that you have listed, I like "indexOfOccurrence" the
> > best. Another one to consider might be "ordinalIndexOf".
> 
> b/w the 2, I like indexOfOccurrence better but let's see what other folks
> like.
> 
> >
> > 2. Make sure to change the method names in the javadoc examples to
> > match the chosen name.  Also, the last two examples should probably be
> > replaced by one using a * for the integer argument.
> 
> I am not fond of that one since I would need to put a "x" or "i" or
> something that is not the real answer to the example and since the point
> of the method is to pass in a count, an example for both 1 and 2 is nice.
> I could add another entry with * and "i" I guess.
> 
> gg
> 
> >
> > Phil
> >
> > >
> > > Gary
> > >
> > >
> > >>-----Original Message-----
> > >>From: Phil Steitz [mailto:phil@steitz.com]
> > >>Sent: Monday, August 25, 2003 20:24
> > >>To: Jakarta Commons Developers List
> > >>Subject: Re: [VOTE] Release of Commons Lang 2.0 [take 2]
> > >>
> > >>Gary Gregory wrote:
> > >>
> > >>>I'll take the blame for causing any confusion on this one since I
> > >>>had committed these Javadoc changes "during" the vote, which was
> > >>>made more difficult due to the extremely long email delays caused
> > >>>by the current
> > >>
> > >>batch
> > >>
> > >>>of viruses going 'round.
> > >>>
> > >>>My thought was that we were indeed voting on the build based on
> > >>>tagged sources and that any new commits would be in a post >2.0
> > >>>release (even though, these changes being Javadoc changes are
> > >>>"harmless" and
> > >>
> > >>beneficial to
> > >>
> > >>>the release IMHO ;-)
> > >>>
> > >>>If we want to implement a code freeze in our environment on top of
> > using
> > >>>tags, we could do that. I guess we'd have to vote on it too :-)
> > >>
> > >>Sorry if I misunderstood things. I thought we were still adding
> > >>things to the release. I see no reason to freeze code if we have a
> > >>tagged release.  I am +1 for releasing the code prior to the javadoc
> > >>changes that occurred during the vote or to adding them and
> > >>retagging. If that requires a new vote, then I am OK with that as
> > >>well.
> > >>
> > >>In any case, we should not have to stop everything as we wait for
> > >>the release to go. I would also very much like to see 2.0 get out
> > >>the door.
> > >>
> > >>Phil
> > >>
> > >>
> > >>>Gary
> > >>>
> > >>>
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: Noel J. Bergman [mailto:noel@devtech.com]
> > >>>>Sent: Sunday, August 24, 2003 00:00
> > >>>>To: Jakarta Commons Developers List
> > >>>>Subject: RE: [VOTE] Release of Commons Lang 2.0 [take 2]
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Well, if there is a question about policy/process, why not just
> > freeze
> > >>>>
> > >>>>the
> > >>>>
> > >>>>
> > >>>>>code and restart the vote?
> > >>>>
> > >>>>By tagging the CVS, he effectively has frozen the code for the
> > Release.
> > >>>
> > >>I
> > >>
> > >>>>was simply curious about the policy because, as I said, other
> > >>>>projects
> > >>>
> > >>are
> > >>
> > >>>>stricter.  For example the HTTPd team has different rules
> > >>>>(http://httpd.apache.org/dev/release.html).
> > >>>>
> > >>>>A Release Manager makes a release build, and it is automatically
> > >>>>an
> > >>>
> > >>alpha.
> > >>
> > >>>>It becomes a beta release when at least three Committers have
> > >>>>voted
> > beta
> > >>>>status, and there are more +1 than -1.  It becomes a GA release
> > >>>>when
> > at
> > >>>>least three Committers vote for GA (stable) status, and there are
> > >>>>more
> > >>>
> > >>+1
> > >>
> > >>>>than -1.  Notice that -1 is not a veto.  Notice, also, that the
> > package
> > >>>>itself may go through multiple status changes, but no packaging
> > changes.
> > >>>>The only allowable change is renaming the file to reflect the
> > >>>>change
> > in
> > >>>>status; exceptions can be made if a change in the contents of the
> > >>>
> > >>tarball
> > >>
> > >>>>(e.g., someone forgot to add the LICENSE file).  Otherwise, if a
> > change
> > >>>
> > >>in
> > >>
> > >>>>the CVS needs to be incorporated, it becomes a new release (with
a
> > >>>>new vote).
> > >>>>
> > >>>>Other projects, such as Avalon, also roll jars and then vote on
> > >>>>them
> > as
> > >>>
> > >>a
> > >>
> > >>>>Release.  So I was just asking to understand what is established
> > >>>>as
> > >>>
> > >>policy
> > >>
> > >>>>here.  I wasn't challenging Henri's release.
> > >>>>
> > >>>>	--- Noel
> > >>>>
> > >>>>
> > >>>>------------------------------------------------------------------
> > >>>>---
> > >>>>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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message