commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [VOTE][Collections] Naming conventions
Date Tue, 25 Jun 2002 12:48:36 GMT
+1

(sorry it took a while to catch up - commons-dev has been very busy lately).

James
----- Original Message -----
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Saturday, June 22, 2002 10:47 PM
Subject: Re: [VOTE][Collections] Naming conventions


> +1
> Stephen
>
> ----- Original Message -----
> From: "Michael A. Smith" <mas@apache.org>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Saturday, June 22, 2002 10:16 PM
> Subject: [VOTE][Collections] Naming conventions
>
>
> > 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>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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