commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <>
Subject Re: [collections] CollectionUtils.index() behavior
Date Mon, 29 Sep 2003 04:23:25 GMT
I don't understand why we are obligated to keep _any_ method.  If we 
don't like it, why not deprecate it for 3.0 and remove in 4.0?

I hear a lot of this in commons, that things can't be changed or removed 
due to backwards compatibility.  I think it's unfortunate that methods 
and concepts defined in a 2.0 version of a component must live on for 
its entire life, no matter how outdated or inconsistent they are.

Isn't this what major-numbered releases are for?  To make revolutionary 
changes when needed?  I think a more aggressive attitude toward change, 
when necessary, can be of great benefit to not only the component 
itself, but also the users, if we can get past the momentary annoyance 
of change.  I may be naive, but I still think that change can be good.

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 :-(
> Stephen
> ----- Original Message -----
> From: "Phil Steitz" <>
>> 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.
>>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:
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:

View raw message