You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Hope, Matthew" <Ma...@capitalone.com> on 2003/08/28 10:48:49 UTC
RE: [pcollections][PROPOSAL] Primitive collections - new sandbox
component from [collections]
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:scolebourne@btopenworld.com]
> 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.
Re: [pcollections][PROPOSAL] Primitive collections - new sandbox
component from [collections]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Yes your right, either direction it goes in, the size constraints on
[collections] and maintaining the modularity are imporant too.
-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" <md...@latte.harvard.edu>
>
>>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:scolebourne@btopenworld.com]
>>>>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: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [pcollections][PROPOSAL] Primitive collections - new sandbox component from [collections]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <md...@latte.harvard.edu>
> 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:scolebourne@btopenworld.com]
> >>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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [pcollections][PROPOSAL] Primitive collections - new sandbox
component from [collections]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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:scolebourne@btopenworld.com]
>>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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [pcollections][PROPOSAL] Primitive collections - new sandbox component from [collections]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
[primitives] is a better name overall, no mystery. And there is probably a
strong correlation between primitive collections and primitive helpers.
After all we can change to pcollections later if needs be.
I would like to get Rodney's views before we move and change his package
however ;-)
Stephen
----- Original Message -----
From: "Hope, Matthew" <Ma...@capitalone.com>
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:scolebourne@btopenworld.com]
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org