-M.
Stephen Colebourne wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
