Actually the new [primitives] will add interfaces and implementations for other collection types. That will increase the size, hence a new project. Also this is a completely independent code base to [collections].
Stephen ----- Original Message ----- From: "Mark R. Diggory" <[EMAIL PROTECTED]> > I think what we may be seeing is a aversion to the size complexity of > the current primitives implementation, this package is very heavy on > abstraction and inheritance hierarchy, I suspect newcomers may be > feeling a bit "overwhelmed" and lost by it. > > However, some of the implementations could be quite valuable. Maybe if > there were some more documentation on its usage and package hierarchy in > the javadoc, like in other areas of Collections, then there would be > less adversity? > > -Mark > > Hope, Matthew wrote: > > > is there much of a link in codebase / use cases of the primitive collections > > and primitive utilities within lang etc... > > > > perhaps a primitives project with a sub package o.a.c.primitive.collections > > would work? > > > > I know I'd be a heavy user of both together. > > > > definitely still useful even when 1.5 boxing happens. > > > > colt has some very impressive primitive maps where you can roll your own > > reasonably simply > > (int -> double, long-->Object, int->int etc provided already but with > > 'template' to sort your own out) long->Object is perfect for massive caches > > of credit card number->Object maps, only about 16MB overhead per million > > entries and still very fast. > > > > they are a mix of licences and I doubt they are apache compatible though. > > > > Matt > > > > > >>-----Original Message----- > >>From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > >>Sent: 27 August 2003 23:48 > >>To: Jakarta Commons Developers List > >>Cc: Søren Bak > >>Subject: [pcollections][PROPOSAL] Primitive collections - new > >>sandbox component from [collections] > >> > >> > >>The attached proposal is to create a new Sandbox project, named > >>[pcollections] to house a complete set of primitive > >>collections. Reasoning: > >> > >>1) [collections] is already large, and primitive-collections > >>and collections > >>actually have remarkably little in common > >> > >>2) The current primitive collections code in [collections] is > >>completely > >>isolated from the rest of the [collections] code, a sure-fire > >>indicator of > >>being better in a separate project with its own release cycle > >> > >>3) A positive response from Soren Bak of the PCJ project to > >>integrate a > >>complete set of primitive-collections together in one place. > >> > >> > >>This mail is to enable anyone to > >>- object to the idea > >>- come up with a better name than pcollections > >>- to volunteer support (please!!) > >>- or any other comment :-) > >> > >>Stephen > >> > >> > > > > > > ************************************************************************** > > The information transmitted herewith is sensitive information intended only > > for use by the individual or entity to which it is addressed. If the reader > > of this message is not the intended recipient, you are hereby notified that > > any review, retransmission, dissemination, distribution, copying or other > > use of, or taking of any action in reliance upon this information is > > strictly prohibited. If you have received this communication in error, > > please contact the sender and delete the material from your computer. > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
