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" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
from: Phil Steitz <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
