----- Original Message ----- From: "Michael A. Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Monday, March 18, 2002 5:09 PM Subject: Re: [COLLECTIONS] [VOTE] Release Collections 2.0
> On Mon, 18 Mar 2002, Morgan Delagrange wrote: > > > 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 > > yeah, I think I did mean ArrayIterator. The simple way of doing this > would be to use Array.getLength(array). That does the checking for you. > It also lets you calculate the length once (in the constructor) so that > multiple calls to hasNext does not require the overhead of > Array.getLength(...). OK, sounds reasonable. FWIW, it may make sense to optimize this class someday, so we don't perform unnecessary reflection on Object[] arrays. > > 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. > > There's probably an argument for keeping it around, but it's not an > argument that I'm going to make. I'm with you on deprecating > ArrayEnumeration. Cool. That's what I'm going to do, then, unless there are complaints. > > > 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. > > Nope. peek() and pop() return Comparables and some of the protected > methods take a Comparable as an argument. Changing these from Comparable > to Object would be an API change because the method signatures would > change. > > If you can hold off on the release for a few days, I can fix the above > mentioned problems. Should be fairly simple to do. > I'll take care of the ArrayIterator and ArrayEnumeration changes right now. If you want to tackle BinaryHeap, it's all yours. Just let us know if it's going to take more than a few days. - Morgan _________________________________________________________ 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]>
