Why state "The API will mimic as closely as possible the object-based API"?
This isn't true of the current codebase (consider InputStreamCharIterator or RandomAccess*List for example, neither of which have direct correlation to anything in java.util) and as a design decision, not an scope one, shouldn't be part of proposal. I think we should strike the sentence under "rationale" reading "The API will mimic as closely as possible the object-based API" and the phrase under "scope" reading "mimicing the object-based API". Similiarly, we should probably add something like "and related types" to the "scope" definition, since things Iterator and other helper types (or for that matter, Map), aren't strictly Collections. On Wed, 8 Oct 2003, Stephen Colebourne wrote: > Reminder!! This vote for a new commons proper component is still open and > awaiting responses. There are 2 +1s and 2 +0s at present so more votes are > needed :-) > Stephen > > PROPOSAL: > <html> > <head> > <title>Proposal for PCollections Package</title> > </head> > <body bgcolor="white"> > > <div align="center"> > <h1>Proposal for <em>PCollections</em> Package</h1> > </div> > > <h3>(0) Rationale</h3> > <p> > The Java Collection Framework defines a well-known and widely used API > for collections. > This framework is object-based, but the Java language also contains > primitive types. > The framework requires each primitive to be wrapped in an object, such > as Integer, > before they can be used in collections. This has a memory and > performance overhead. > </p> > <p> > The pcollections component will provide an API for collections based on > primitives > The API will mimic as closely as possible the object-based API. > Wrappers and adaptors will be provided for integration with the > object-based API. > </p> > > <h3>(1) Scope of the Package</h3> > <p> > The package will create and maintain a set of collections for primitive > types, > mimicing the object-based API, distributed under the ASF license. > </p> > > <h3>(1.5) Interaction With Other Packages</h3> > <p> > <em>PCollections</em> relies only on standard JDK 1.2 (or later) APIs for > production deployment. It utilizes the commons-collections test framework > and the JUnit unit testing framework for developing and executing unit > tests, > but this is of interest only to developers of the component. > </p> > <p> > No external configuration files are utilized. > </p> > > <h3>(2) Initial Source of the Package</h3> > <p> > The initial codebase is taken from commons-collections, where it was > unreleased. > </p> > > <p>The proposed package name for the new component is > <code>org.apache.commons.pcollections</code>.</p> > > > <h3>(3) Required Jakarta-Commons Resources</h3> > <ul> > <li>CVS Repository - New directory <code>pcollections</code> in the > <code>jakarta-commons</code> CVS repository.</li> > <li>Mailing List - Discussions will take place on the general > <em>[EMAIL PROTECTED]</em> mailing list. To help > list subscribers identify messages of interest, it is suggested that > the message subject of messages about this component be prefixed with > [pcollections].</li> > <li>Bugzilla - New component "PCollections" under the "Commons" product > category, with appropriate version identifiers as needed.</li> > <li>Jyve FAQ - New category "commons-pcollections" (when available). > </ul> > > > <h3>(4) Initial Committers</h3> > <ul> > <li>Rodney Waldhoff</li> > <li>Stephen Colebourne</li> > </ul> > </body> > </html> > > > ----- Original Message ----- > From: "Stephen Colebourne" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Tuesday, October 07, 2003 1:06 AM > Subject: [VOTE] New commons proper component - pcollections > > > > The [collections] component has been housing unreleased, but stable > > primitive collections code for some time. These are collections that store > > primitive arrays behind the scenes instead of objects. (Note that JDK1.5 > > does NOT address the need for these classes). > > > > Following discussion within the [collections] component on the best > release > > strategy, we would like to create a new commons-PROPER component to house > > the code. The aim is to give this useful code room to grow without > impacting > > the widely used main [collections] (object-based) component. > > > > It is important to emphasise that this is not new code - it is stable and > > ready for release. Thus commons-proper, rather than the sandbox, is the > > appropriate place for the new component. > > > > The proposal is attached for the new component 'pcollections'. (No one > likes > > this name, but we haven't found a better one). > > > > Please vote as to whether you support this new commons-PROPER component. > > [ ] +1 Yes, lets create [pcollections] > > [ ] +0 > > [ ] -0 > > [ ] -1 No, I oppose this because.... > > > > Stephen > > > > > ---------------------------------------------------------------------------- > ---- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- - Rod <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
