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]
