commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <...@apache.org>
Subject Re: [VOTE][Collections] Naming conventions
Date Tue, 25 Jun 2002 11:51:24 GMT
On Tue, 25 Jun 2002, Juozas Baliuka wrote:
> Hi,
> I agree, new naming is better, but can't find message with Aaron's -1,
> I want to know his motivation  before to vote.

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=374225

regards,
michael

> ----- Original Message -----
> From: "Michael A. Smith" <michael@iammichael.org>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Tuesday, June 25, 2002 5:41 AM
> Subject: Re: [VOTE][Collections] Naming conventions
> 
> 
> > It's possible this has been drowned out by the recent maven
> > and "core/lang/util" discussions, so I'm sending this out for any other
> > comments/votes.
> >
> > regards,
> > michael
> >
> >
> > On Sat, 22 Jun 2002, Michael A. Smith wrote:
> > > There has been recent discussion on this list about forming naming
> > > conventions for the collections component to ensure consistency within
> > > the collections API as more and more collection "decorators" are added.
> > > The discussion culminated in a summary by Stephen:
> > >
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apac
> he.org&msgId=366210
> > >
> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=102416074321189&w=2
> > > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg08316.html
> > > [use whatever archive you prefer]
> > >
> > > Since the changes are considered a product change, they are governed by
> > > the lazy consensus voting rules which state that approval is assumed
> > > until a -1 occurs (at which point it reverts to consensus).  Aaron Bates
> > > has -1 the laziness, and thus this is now a consensus vote.  Thus, we
> > > need 3 +1 votes and no -1 votes in order to adopt the proposal.  [*]
> > >
> > >
> > > I'd like to start with my +1 for the proposal.  It doesn't have any
> > > compatibility impact since almost all the code has been added since the
> > > last collections release, and will make usage of the API much more
> > > straightforward.  Maintenance may require more effort, but the proposal
> > > allows for reducing the maintenance if required (i.e. move the static
> > > inner classes as top level classes in a subpackage).
> > >
> > > regards,
> > > michael
> > >
> > > [*] See: http://jakarta.apache.org/site/decisions.html
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message