It seems to me that this sort of thing should be able to be handled by lazy consensus. From Stephen's remarks, it appears that he is -1 to deprecation without replacement, which means to me that there is no consensus on deprecation without replacement, so we should either leave it alone (which I don't think anyone who has looked carefully at the code would support) or deprecate with replacement.
My short term plan, which I will carry out when I get back from travelling this Thursday, is to deprecate the current method and replace it with another method in CollectionUtils named something like "getIndex" (or maybe just "get") with the API that Stephen proposed above. This plan is itself subject to lazy consensus, so if any "-1s" appear in the next couple of days, I will not follow through with it.
Phil
I have committed the changes to add get(object, index) and deprecate the index(-,-) methods. I decided not to return null for index values out of range or unsupported object types; however, because this would be ambiguous (objects could contain nulls). The current implementation throws ArrayIndexOutOfBoundsException and IllegalArgumentException in these cases. I am open to suggestions for how to handle these cases differently if others do not like this.
Phil
__matthewHawthorne wrote:
What do you think Phil, is a vote for deprecation with no replacement desirable?
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
--------------------------------------------------------------------- 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]
