commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [VOTE][Collections] Naming conventions
Date Tue, 25 Jun 2002 05:12:54 GMT
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.

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


Mime
View raw message