On Wed, 3 Sep 2003, Stephen Colebourne wrote: sc> From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
rw> > * I'm -1 to moving collections.primitives, or more generally, rw> > any release ready code, to the sandbox, as this moves it rw> > further away from a release rather than closer. sc> I'm balancing this worry with the desire to not release something new sc> that is in the wrong place. The basic issue is that primitive sc> collections are quite disconnected (ie. totally) from the rest of sc> the package. This argues sc> for a separate project, as you have done in the sc> past over parts of lang (which has happened). What I have argued in the past, and I'll argue now, is that cohesive components are constructed out of classes that are (a) interdependent, (b) commonly used together, and/or (c) commonly change together. Adapters and test suites aside, currently collections.* and collections.primitives.* fail the first test but pass the second two. Of course, many of the collections.* classes have this profile, for just one example, LRUMap and ArrayIterator. 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]. Except that the unit testing framework isn't currently distributed in any form. This is a compile-time (or test-time) dependency on code that's currently internal to the commons-collections code base. rw> > b) It is quite likely that we'll eventually want primitive rw> > implementations of Bag and other commons-collections-only rw> > extensions, which would introduce direct rw> > collections/primitive-collections dependencies, at rw> > least at the adapter level. This would also imply that rw> > collections and primitive-collections packages are likely to change rw> > together, since changes to commons-collections extensions would rw> > imply changes to the primitive collections. sc> Primitive collections may depend on the Bag interface, but sc> probably little else. >From a quick glance, Bag, BoundedCollection, Buffer, MultiMap, OrderedMap, OrderedSet, PriorityQueue, ResetableIterator, ResetableListIterator and SortedBag all seem like interfaces that we'd quite likely want to support within the primitive collections sooner or later. Many interfaces that aren't commonly implemented via decorators would likely fall into this category as well. Any change to the object based implementations will likely necessitate a change in the primitive implementations and/or their adapters. sc> This could be solved by adding a [collections] dependency, or by sc> simply including the Bag interface in the primitive-collections jar. sc> (I know that sounds scary, but an isolated interface, thus sc> non-changing, should be fine in two jars) This is indeed one approach, but what problem are we trying to solve? rw> > * I'm +0 to having the commons-collections component release rw> > multiple JARs, for example, commons-collections.jar (everything rw> > minus *.primitives), commons-collections-primitives.jar rw> > (*.primitives.*), and rw> > commons-collections-all.jar (everything). sc> I'm -0.5 to this approach. I think it confuses users "Primitive collections are there, object collections are here", what's confusing about that? How's [pcollections] and [collections] less confusing, or for that matter, different? sc> and leads to classpath issues with the same class in two jars. Fair enough, so drop commons-collections-all.jar. 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"? sc> Well, comparators aren't actually collections. Plus Mutable priimtive sc> wrapper classes are also possibilities. Primitive comparators are pretty much defined by the built-in operators (either '-' or '<'), and/or by auto-boxing. (And the most common use of comparators is handled by java.util.System methods anyway). Currently object-level comparators are in collections, so I don't think this is making the problem any worse. (Not that there are primitive comparator implementations in the code base currently anyway). Arguably there is overlap with lang, math, collections and functor on this point. sc> PROPOSAL: sc> We copy the existing [collections] primitive code to a new sc> sandbox project [pcollections] unaltered except for the package name. sc> (I've already tried this locally and it works). (Thus I volunteer for sc> this) sc> sc> [pcollections] and [primitives] can then cooexist, and Darwin will sc> then decide. If you want to push for [pcollections] promotion and sc> release, that will be your call. Alternatively you could wait a month sc> or so to see how [primitives] turns out :-) 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. As before, I'm -1 to moving code from commons.collections.primitives into the sandbox, since: (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. (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 (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=7694), as did a total of 4 committers (with no dissenters). (d) When viewed through a common-use or common-cause-for-change metric, the primitive collections and the collections packages have very high cohesion. Indeed, they have higher cohesion on the latter point than most arbitrary pairs of types in commons-collections. sc> This actually works well, as I want to try implementing [primitives] sc> as direct implementations of List, Collection, Map et al. - no sc> separate adaptors. So, there is a good case for the separation. As you are well aware, we've played with this approach in the past and found it wanting. Among other drawbacks, you lose the ability to use the primitive collections independent of the java.util Collections (for example on many micro and J2ME platforms). Perhaps more importantly, the pollution of the namespace becomes significant, a point that you and others have noted in the past: <http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=504141> (On this note, your preferences on the "design decisions" thread seem inconsistent on this point. You state a preference for extending the Collections interfaces (e.g., "IntCollection extends Collection"), but you also state a preference for not "following the Sun Framework closely".) Having authored and extensively worked with the code both ways, personally I strongly prefer the adapter approach utilizing small, focused, composable pieces. 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. Specifically, I'm not strictly opposed to introducing a [primitives] or [pcollections] component that contains what's currently org.apache.commons.collections.primitives.* and whatever else seems to fit well. (Although I'm not confident that's a good idea either.) I am opposed to moving code from commons proper to the sandbox for that purpose. - Rod <http://radio.weblogs.com/0122027/> sc> Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
