commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] CollectionUtils.index() behavior
Date Sun, 28 Sep 2003 22:46:30 GMT
I can't think of a good alternate name. Maybe getIndex() on CollectionUtils?

Stephen

----- Original Message -----
From: "Phil Steitz" <phil@steitz.com>
> 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 :-(
>
> OK, but do you still feel that the "improved" index(Object, int) belongs
> in IteratorUtils and not CollectionUtils?  I guess the name would have
> to be changed if it is left in CollectionUtils...
>
> Phil
>
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Phil Steitz" <phil@steitz.com>
> >
> >>scolebourne@btopenworld.com wrote:
> >>
> >>>>from:    Phil Steitz <phil@steitz.com>
> >>>>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: 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
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


Mime
View raw message