commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [collections] CollectionUtils.index() behavior
Date Fri, 26 Sep 2003 13:41:02 GMT
Stephen Colebourne wrote:
> From: "Phil Steitz" <>
>>Grr. Just discovered another wonderful "feature" when implementing a
>>test for this.  Since the algorithm for index(map, i) first tries to
>>find Integer(i) as a key in the map, if you use a TreeMap to test, this
>>throws a ClassCastException unless the keys in the map are Integers.
>>I guess this is more or less implied by the javadoc, which describes the
>>algorithm, but I am thinking now that it might be better to catch the
>>ClassCastException (or maybe even Exception) in the first attempted
>>lookup and let it drop through to the iterator. This would make the
>>method usable for Sorted Maps with non-integer keys.  Any objections to
>>this change?
> +1, however the more I look......
> An alternative would be to deprecate it and write a version on IteratorUtils
> that only has the index(Object, int) syntax. I have no idea who would use
> this method, and it is just seriously weird.

Agreed.  If there are no objections, I will do this.

> A sensible API would be:
> Gets the nth index in the object specified. The object may be an array,
> collection, iterator, enumeration or map. Returns null if no matching
> element.

Certainly better than the current method.  In the case of a Map, by the 
"matching element", which do you mean

a) the nth element of the keySet (like now)
b) the nth Map.Entry of the entrySet (best, IMHO) or
c) the value of the nth entry of the entrySet?


> Stephen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message