I'm with Gary on the +0. First off, I think that [pcollections] is conceptually within the [collections] realm. People will be confused as to why it is a separate jar.
However, if it only supports a Collections API, then it's not going to be as good as it should. It should have a primitive API as well. Splitting pcollections out has some definite perks though. Firstly it separates the releases to avoid two separate codebases having to release together. This is a big advantage. Secondly, it will help to highlight the pcollections code, without any JDK 1.6 [or something] problems when pcollections becomes unnecessary. Lastly, I've not seen a -1 from a collections developer. Rodney and Stephen seem to be agreed on it, so it's a choice I'm perfectly willing to follow. Hen On Tue, 7 Oct 2003, Gary Gregory wrote: > Ok, I change my vote to 0. > > We do use [collections] in our product but I am not coding with it right now > so I will defer to you guys as to the ease of working with a mixed (Integer > and int) collections model and other details. > > Gary > > > -----Original Message----- > > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, October 07, 2003 13:21 > > To: Jakarta Commons Developers List > > Subject: Re: [VOTE] New commons proper component - pcollections > > > > MH> 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. > > > > MH> 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 must strongly agree with what Matthew says here. The difference between > > collections and primitive collections seems very subtle and minor from a > > high level view. It seems perfectly natural to think of them together. > > > > However, when you get down to the low level you actually find them quite > > different. [collections] provides additions to an established framework in > > the JDK. pcollections creates something wholely new, styled after an > > existing API. > > > > This is demonstrated most clearly in the fact that the two groups of code > > are entirely independent. Each can be compiled without the other. (Except > > the test cases, and that has been dealt with) Other differences include > > the > > way code is developed, with pcollections potentially using code generation > > at some point. > > > > There is an additional point, in that [collections] is very widely > > dispersed > > and used. To increase its size by over 100% suggests that something should > > at least be looked at. > > > > MH> 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. > > > > > GG> 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. > > It still is, but we ask you to include an additional jar. > > > > MH> 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. :-) > > I'm very clear that it is good to split, manage and release separately in > > this case. > > > > GG> Good chat, thanks. > > Ah, but we are lobbying for you to change your vote. If not to +1, at > > least > > to a 0. We need to convince you ;-) > > > > Stephen > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
