You're the one who sparked the discussion, I was just chiming in with some general noise.
Stephen Colebourne wrote:
Yes, change can be good, and deprecating and changing does happen. The trouble with removing is that there is nowhere for users to go to. And we just don't know who the users are.
There is some useful functionality here. Its a little odd, but perhaps in a untyped system like [beanutils] or [el], this kind of method might be useful.
Perhaps you should start a vote for deprecation no replacement?
Stephen
----- Original Message ----- From: "__matthewHawthorne" <[EMAIL PROTECTED]>
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" <[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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
