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 Fri, 05 Sep 2003 00:15:38 GMT
Inline, snipped as much as I sensibly could.
From: "Rodney Waldhoff" <>
> rw> > a) The two code bases are not truly independent, they share
> rw> > a unit test suite, so if we split the two we'll probably want
> rw> > to extract the shared unit testing framework.
> sc> I would see this as a compile-time dependency on [collections].
> rw> Except that the unit testing framework isn't currently distributed in
> rw> form.  This is a compile-time (or test-time) dependency on code that's
> rw> currently internal to the commons-collections code base.
The unit testing framework is distributed in the collections source zip
file, so is available. I think that this could be communicated to users.

> rw> > b) It is quite likely that we'll eventually want primitive
> rw> > implementations of Bag and other commons-collections-only
> rw> > extensions,...
> sc> Primitive collections may depend on the Bag interface, but
> sc> probably little else.
> rw>From a quick glance, Bag, BoundedCollection, Buffer, MultiMap,
> rw> OrderedSet, PriorityQueue, ResetableIterator, ResetableListIterator
> rw> SortedBag all seem like interfaces that we'd quite likely want to
> rw> within the primitive collections sooner or later.  Many interfaces
> rw> aren't commonly implemented via decorators would likely fall into this
> rw> category as well.  Any change to the object based implementations will
> rw> likely necessitate a change in the primitive implementations and/or
> rw> adapters.
There is definitely a case for a dependency here if more interfaces are to
be implemented. Of course at present, none are. This could be solved either
by hiding the dependency within collections, or exposing it by adding a
separate project.

> rw> > multiple JARs, for example, commons-collections.jar (everything
> rw> > minus *.primitives), commons-collections-primitives.jar
> rw> > (*.primitives.*)
> rw> "Primitive collections are there, object collections are here", what's
> rw> confusing about that?  How's [pcollections] and [collections] less
> rw> confusing, or for that matter, different?
I prefer one project to release one jar with one package name structure.

> rw> > * I'm unsure about the notion of "primitives" as opposed to
> rw> > "primitive collections".  Precisely what non-collection stuff
> rw> > do we believe to be in scope for "primitives"?
A better answer to this question is I don't know yet :-) I see [primitives]
as being sandbox-like at present, exploring options and seeing if a
community develops.

> Independent of moving the component or jar distributions around, I'm -1 to
> repackaging code from org.apache.commons.collections.primitives at this
> time.  I've already got a significant (and for the record, largely open
> source) body of code dependent on the current implementation and the
> current packaging, as well as a substantial installed user base.
> Repackaging this code to move or remove the word "collections" seems to
> create a lot of trouble with little if any benefit.  I can't imagine what
> else would go into that namespace anyway, so if we're going to change it,
> it should be done via a slow deprecation rather than by fiat.
IMHO unreleased code is liable to change, whether in the sandbox or not.

To explain further, my preferred approach to managing the commons projects
I'm involved in is to let code be added to CVS, then to radically refactor
just before a release. This is because it is only when you have all the code
that you can see what should be moved/removed/renamed.

For [lang] this worked well. Once release was getting close, the functor and
reflect code was reviewed and removed and the util package disbanded. IMHO
this late refactoring approach works well.

> (a) The code is well within the scope of commons-collections, so demoting
> it for the sole purpose of removing it from commons-collections seems
> questionable at best.
> (b) The code is well over a year old, stable, 100% tested, and well used
> in production environments (including two generations of commercial,
> off-the-shelf products), and other open source projects (including some
> here in commons) use or have expressed an interest in using these classes.
> Moving this stuff further away from a formal release is a disservice to
> those users.
I am happy for the code to be placed in a new commons proper component
instead of the sandbox. I would volunteer to create the new component but
not release it.

> (c) Adding the primitive collections to the commons-collections code base
> is an old decision that was openly discussed on this list.  Indeed, you
> yourself expressed approval for this action
> as did a total of 4 committers (with no dissenters).
Both Object and Primitive collections have grown since then. I'm trying to
avoid serious class overload if Maps and Sets get added too.

> sc> How does this sound???
> As before, I'm open to (a) leaving the primitive collections where they
> are, (b) splitting the distribution of commons-collections into primitive
> and object based implementations or (c) proposing a new commons proper
> component, dependent upon commons-collections, containing the primitive
> collections and possibly more.  Note that to do (c) will require
> re-implementing, copying, refactoring or releasing the commons-collections
> test framework.
I prefer (c) and I don't believe it requires a release of the testing
framework beyond that of the collections source zip.

If I am forced, I will accept (b) although it doesn't feel right to me.

In addition, I wish to continue working on [primitives] in the sandbox with
the no adaptors design. It may be the case that both designs have their


View raw message