commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [primitives][collections] primitive collections and PROPOSAL
Date Wed, 03 Sep 2003 21:21:53 GMT
Inline, with PROPOSAL at bottom.

From: "Rodney Waldhoff" <>
> * I'm -1 to moving collections.primitives, or more generally, any release
> ready code, to the sandbox, as this moves it further away from a release
> rather than closer.
I'm balancing this worry with the desire to not release something new that
is in the wrong place. The basic issue is that primitive collections are
quite disconnected (ie. totally) from the rest of the package. This argues
for a separate project, as you have done in the past over parts of lang
(which has happened).

> a) The two code bases are not truly independent, they share a unit test
> suite, so if we split the two we'll probably want to extract the shared
> unit testing framework.
I would see this as a compile-time dependency on [collections].

> b) It is quite likely that we'll eventually want primitive implementations
> of Bag and other commons-collections-only extensions, which would
> introduce direct collections/primitive-collections dependencies, at least
> at the adapter level.  This would also imply that collections and
> primitive-collections packages are likely to change together, since
> to commons-collections extensions would imply changes to the primitive
> collections.
Primitive collections may depend on the Bag interface, but probably little
else. This could be solved by adding a [collections] dependency, or by
simply including the Bag interface in the primitive-collections jar. (I know
that sounds scary, but an isolated interface, thus non-changing, should be
fine in two jars)

> * I'm +0 to having the commons-collections component release multiple
> JARs, for example, commons-collections.jar (everything minus
> *.primitives), commons-collections-primitives.jar (*.primitives.*), and
> commons-collections-all.jar (everything).
I'm -0.5 to this approach. I think it confuses users and leads to classpath
issues with the same class in two jars.

> * I'm unsure about the notion of "primitives" as opposed to "primitive
> collections".  Precisely what non-collection stuff do we believe to be in
> scope for "primitives"?
Well, comparators aren't actually collections. Plus Mutable priimtive
wrapper classes are also possibilities.

We copy the existing [collections] primitive code to a new sandbox project
[pcollections] unaltered except for the package name. (I've already tried
this locally and it works). (Thus I volunteer for this)

[pcollections] and [primitives] can then cooexist, and Darwin will then
decide. If you want to push for [pcollections] promotion and release, that
will be your call. Alternatively you could wait a month or so to see how
[primitives] turns out :-)

This actually works well, as I want to try implementing [primitives] as
direct implementations of List, Collection, Map et al. - no separate
adaptors. So, there is a good case for the separation.

How does this sound???


View raw message