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 Mon, 29 Sep 2003 21:25:40 GMT
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" <matth@phreaker.net>
> 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" <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
>


Mime
View raw message