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]
