You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2003/09/21 02:12:20 UTC
[collections] CollectionUtils.index() behavior
Currently, if obj is a Map or a Collection (but not a List) and index is
an Integer, CollectionUtils.index(obj,index) will return the index-th
object returned by an iterator over the map/collection. Since there is
no guaranteed order in these cases, it does not make sense to me for
index() to be defined in these cases.
Should this be changed to either follow the "default" path (returning
obj) or to throw an IllegalArgumentException?
Phil
Re: [collections] CollectionUtils.index() behavior
Posted by Phil Steitz <ph...@steitz.com>.
Stephen Colebourne wrote:
> Although I agree that the definition of using the Iterator is potentially
> dangerous, it often works as iterators generally are consistent.
>
> This method is one of the originals from this class, and is documented as to
> what it does, so I'm -1 to changing it.
OK, I will leave as is, but I personally see this as bad design -- maps
are not ordered and what this method does is essentially add a method
not supported by the data structure. Test cases look a bit silly (all
you can test if that index(map, index) returns an entry from the map)
and the doc needs to be improved a bit to explain exactly what happens
with maps. Specifically:
1. index(map,index) behaves differently if map contains an Integer key
with value = index (in which case it returns the corresponding value)
vs. when there is no Integer key with value = index, in which case the
indexth *key* is returned.
2. if index(map, index) does not exist, what is returned is an iterator
over the *keyset* (not the values)) rather than the map.
I will try to clarify the docs (without making things too complicated)
and add test cases to confirm.
Phil
>
> Stephen
>
> ----- Original Message -----
> From: "Phil Steitz" <ph...@steitz.com>
>
>>Currently, if obj is a Map or a Collection (but not a List) and index is
>>an Integer, CollectionUtils.index(obj,index) will return the index-th
>>object returned by an iterator over the map/collection. Since there is
>>no guaranteed order in these cases, it does not make sense to me for
>>index() to be defined in these cases.
>>
>>Should this be changed to either follow the "default" path (returning
>>obj) or to throw an IllegalArgumentException?
>>
>>Phil
>>
>>
>>
>>---------------------------------------------------------------------
>>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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] CollectionUtils.index() behavior
Posted by Phil Steitz <ph...@steitz.com>.
Stephen Colebourne wrote:
> Although I agree that the definition of using the Iterator is potentially
> dangerous, it often works as iterators generally are consistent.
>
> This method is one of the originals from this class, and is documented as to
> what it does, so I'm -1 to changing it.
OK, I will leave as is, but I personally see this as bad design -- maps
are not ordered and what this method does is essentially add a method
not supported by the data structure. Test cases look a bit silly (all
you can test if that index(map, index) returns an entry from the map)
and the doc needs to be improved a bit to explain exactly what happens
with maps. Specifically:
1. index(map,index) behaves differently if map contains an Integer key
with value = index (in which case it returns the corresponding value)
vs. when there is no Integer key with value = index, in which case the
indexth *key* is returned.
2. if index(map, index) does not exist, what is returned is an iterator
over the *keyset* (not the values)) rather than the map.
I will try to clarify the docs (without making things too complicated)
and add test cases to confirm.
Phil
>
> Stephen
>
> ----- Original Message -----
> From: "Phil Steitz" <ph...@steitz.com>
>
>>Currently, if obj is a Map or a Collection (but not a List) and index is
>>an Integer, CollectionUtils.index(obj,index) will return the index-th
>>object returned by an iterator over the map/collection. Since there is
>>no guaranteed order in these cases, it does not make sense to me for
>>index() to be defined in these cases.
>>
>>Should this be changed to either follow the "default" path (returning
>>obj) or to throw an IllegalArgumentException?
>>
>>Phil
>>
>>
>>
>>---------------------------------------------------------------------
>>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
>
Re: [collections] CollectionUtils.index() behavior
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Although I agree that the definition of using the Iterator is potentially
dangerous, it often works as iterators generally are consistent.
This method is one of the originals from this class, and is documented as to
what it does, so I'm -1 to changing it.
Stephen
----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
> Currently, if obj is a Map or a Collection (but not a List) and index is
> an Integer, CollectionUtils.index(obj,index) will return the index-th
> object returned by an iterator over the map/collection. Since there is
> no guaranteed order in these cases, it does not make sense to me for
> index() to be defined in these cases.
>
> Should this be changed to either follow the "default" path (returning
> obj) or to throw an IllegalArgumentException?
>
> Phil
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [collections] CollectionUtils.index() behavior
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Although I agree that the definition of using the Iterator is potentially
dangerous, it often works as iterators generally are consistent.
This method is one of the originals from this class, and is documented as to
what it does, so I'm -1 to changing it.
Stephen
----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
> Currently, if obj is a Map or a Collection (but not a List) and index is
> an Integer, CollectionUtils.index(obj,index) will return the index-th
> object returned by an iterator over the map/collection. Since there is
> no guaranteed order in these cases, it does not make sense to me for
> index() to be defined in these cases.
>
> Should this be changed to either follow the "default" path (returning
> obj) or to throw an IllegalArgumentException?
>
> Phil
>
>
>
> ---------------------------------------------------------------------
> 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