commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [collections] CollectionUtils.index() behavior
Date Sun, 28 Sep 2003 21:59:28 GMT
Stephen Colebourne wrote:
> I don't have as strong reservations as you. I would suggest that the test
> should assume that the iterator order of a Collection/Map remains constant
> so long as no new elements are added. Sure its not in the interface, but its
> generally true.
> 
> I see this method as being one we wouldn't allow into [collections] now, but
> as we have it we must keep it. So its about making it as good as possible.
> Not ideal, but thats history for you :-(

OK, but do you still feel that the "improved" index(Object, int) belongs 
in IteratorUtils and not CollectionUtils?  I guess the name would have 
to be changed if it is left in CollectionUtils...

Phil

> 
> Stephen
> 
> ----- Original Message -----
> From: "Phil Steitz" <phil@steitz.com>
> 
>>scolebourne@btopenworld.com wrote:
>>
>>>>from:    Phil Steitz <phil@steitz.com>
>>>>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.
>>
>>Phil
>>
>>
>>
>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




Mime
View raw message