----- Original Message ----- From: "Michael A. Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Sunday, March 17, 2002 11:00 PM Subject: Re: [COLLECTIONS] [VOTE] Release Collections 2.0
> On Fri, 15 Mar 2002, Morgan Delagrange wrote: > > The release candidate is ready and sitting on the server: > > > > http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections > > /v2.0/ > > > > Please state your vote for this candidate. Also, please let me know if you > > discover errors in the distribution. > > -0 on the release. I don't want to hold it up, but I feel there are still > some issues that could be resolved before we actually release a 2.0. > > As I mentioned earlier, documentation definately needs to be improved, but > that could be added in a 2.0.1 without too much problems. Another thing > that I think could be improved is argument checking. > > For example, ArrayEnumeration takes an Object as a parameter, but does not > provide checking on that to ensure that it is actually an Array. The > checking would eventually be provided when the hasNext or next methods are > called (in the form of an IllegalArgumentException), but I feel this > should really be thrown from the constructor and and the setArray methods. > That is, a more fail-fast behavior. Dang nabbit, now you've made me think. ArrayEnumeration actually takes Object[] as its parameter, I think you're thinking of ArrayIterator. But you are right, it would be nice if ArrayIterator was fail-fast. Unfortunately I can't think of a way to do it that's not really hokey. ArrayIterator can take an array of primitives, and there is no specific operation I know of to determine if an Object is an array of primatives. :P ArrayIterator takes primitives and ArrayEnumeration doesn't. :P Should we fix ArrayEnumeration? Or maybe we should deprecate the class and encourage users to wrap ArrayIterator with IteratorEnumeration instead. I think the latter would be my vote. We shouldn't really need to have any Enumeration classes around, since they can always be wrapped. > > Changing such argument checking may be construed as an incompatible > change, so that may not be able to be fixed in a 2.0.1 or a 2.1. > > Another thing on I'd like to see is full generalization of some of the > collections. For example, the BinaryHeap is currently restricted to > Comparable objects. While you can't really have a heap without the > ability to compare the objects, that doesn't mean the objects themselves > have to be comparable. It should be allowable to specify a Comparator and > use that to compare objects that don't implement Comparable. Such a > change would alter the signatures of a couple of methods and would be an > non-backwards compatible change. That only sounds like more constructors, right? You could probably do that in a minor release, especially considering BinaryHeap is neither Serializable nor subclass-able. > > regards, > michael _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
