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 Sat, 27 Sep 2003 20:32:13 GMT wrote:
>> from:    Phil Steitz <>
>>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?
> (b) seems best.
> Stephen

I started work on this, but I am hesitating for three reasons:

1) My initial reservations about the index method being applied to 
unordered maps/collections.  The test cases can only check that 
index(obj, index) returns an element of obj.  Strictly speaking, we 
cannot even guarantee that calling index(obj, index) in a loop will 
effectively iterate the map/collection, or that if i and j are distinct, 
index(obj, i) will be different from index(obj, j). Both of these 
require assumptions about consistency in iterator order that are not 
part of the Map or Collection interface contracts. All of this points to 
the inappropriateness of the API for these kinds of objects, IMO.

2) I am not sure that this method fits in IteratorUtils.

3) Essentially the same functionality is available by using the 
IteratorUtils getIterator and toList methods (with the exception that 
for a Map, getIterator returns an iterator over the values in the map, 
rather than the entrySet).

I suggest therefore that we deprecate the index methods in 
CollectionUtils and that we do not replace them.


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

View raw message