Please see below. > -----Original Message----- > From: __matthewHawthorne [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 07, 2003 11:27 > To: Jakarta Commons Developers List > Subject: Re: [VOTE] New commons proper component - pcollections > > In prowling this list, I've heard the "too many jars" argument very > frequently. I think that I understand the complaint, but I have trouble > understanding the boundaries. When making decisions of this kind, I > think that it's not only important to consider the users, but also the > codebase itself.
We could argue 'round and 'round but since this is not the most important point to me right now I'll let it drop for brevity's sake. > While everyone is free to vote for whatever they want for whatever > reason they wish, voting -1 to a proposal because it will create another > jar doesn't seem right to me. How hard is it, really, to deal with > another jar. You add another entry to your project.xml. You add > another file to a directory. I understand that some production > environments are not this free-spirited, but there has to be a limit. I agree with you in principle here. A -1 just for that reason is not what I meant to express. > Take a look at the codebase for [collections]. It's monstrous. Think > about the un-object-oriented-ness required for building a primitive > collections library. There already are an unbelievable amount of > primitive classes, and there will continue to be more. Now it sounds like [primitives] is a better project name than [pcollections]. In any case, my feeling is that size is, er, relative and should not alone direct the jarring of a component. In my mind, I would like to have [collections] be "all things collection". > The scope and purpose of the [pcollections] and [collections] components > are quite different. The first is extensions and utilities for working > with the collections framework. The second involves the creation a new > primitive implementation which is similar to the collections framework. I think I see your point but... the way I see it (perhaps too simplistically) is like this: "I want a typed Bag of DooDad's, ah! this [collection] class will help me." And "I want a Bag of int's", ah! same answer as above. To me, this is all in the same conceptual lump. Ok, here is my main point: I seems nice and in-sync and well thought out if the /same/ library lets me use a /Collection of Integers/ or a /Collection of ints/. Maybe there even is some cross-conversion methods to let me try and measure it different both ways in my app. > In my opinion, there will not be much overlap. > > I've done some pseudo-ranting here, and I apologize, Not at all! This is all very civilized :-) > but my point is: > These projects are more different than they appear, and adding another > jar is a small price to pay for the proper separation and encapsulation > of code. Ah... but from an app writer's POV, it would be nice it all appeared seamless. I've not had the need yet for this but I would have that porting from a Collection of Integers (CollectionUtils.typedCollection(collection Integer.class) and a Collection of ints (new ArrayIntList()) would be easy. For example, why not implement an RandomAccessIntList.add(Number) to help in this direction? When there are too many lines of code, it's good to split one > class into many. When there are too many classes, and a distinct > separation appears between groups of those classes, it may be good to > split one component into many. Yes, it "may" be, or not. :-) Good chat, thanks. Gary > > > > > Gary Gregory wrote: > > > 1-, I think... > > > > I am in favor of primitives support IN [collection] proper, /especially/ > > since 1.5 will not address this issue. For a feature that 1.4 or 1.5 > would > > address I would see as a good thing a separate Jar for pre-1.4 or pre- > 1.5 > > setups. For example, in [lang], having the nested exception classes in > the > > jar is obviously duplicative in a 1.4 setup. > > > > Now, I do recall some thread on this list about primitives collections > but I > > do not recall if any agreement came on package names or 'jaring'. > > > > My concerns are (feel free to pour gas and set on fire any of these): > > > > (1) One more Jar file to keep track of on the class path, with this > email > > list, with our product build, our customers, etc. All the pain that > comes > > with having yet one more jar dependency in a product. > > > > (2) Conceptually, [collections] is one nice lump. Splitting it for > > collections of primitives vs. Objects is a subtlety I do not want 2 jars > > for, 2 packages fine but not two jars. > > > > Will one jar depend on the other? > > > > Gary > > > > > >>-----Original Message----- > >>From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > >>Sent: Monday, October 06, 2003 17:06 > >>To: Jakarta Commons Developers List > >>Subject: [VOTE] New commons proper component - pcollections > >> > >>The [collections] component has been housing unreleased, but stable > >>primitive collections code for some time. These are collections that > store > >>primitive arrays behind the scenes instead of objects. (Note that JDK1.5 > >>does NOT address the need for these classes). > >> > >>Following discussion within the [collections] component on the best > >>release > >>strategy, we would like to create a new commons-PROPER component to > house > >>the code. The aim is to give this useful code room to grow without > >>impacting > >>the widely used main [collections] (object-based) component. > >> > >>It is important to emphasise that this is not new code - it is stable > and > >>ready for release. Thus commons-proper, rather than the sandbox, is the > >>appropriate place for the new component. > >> > >>The proposal is attached for the new component 'pcollections'. (No one > >>likes > >>this name, but we haven't found a better one). > >> > >>Please vote as to whether you support this new commons-PROPER component. > >>[ ] +1 Yes, lets create [pcollections] > >>[ ] +0 > >>[ ] -0 > >>[ ] -1 No, I oppose this because.... > >> > >>Stephen > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
