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(...). > 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. > > 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. regards, michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
