Re: [collections] CollectionUtils.index() behavior

[Phil Steitz <ph...@steitz.com>]

Phil Steitz wrote:
> 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: 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