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 leav
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
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
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], t
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 define
I can't think of a good alternate name. Maybe getIndex() on CollectionUtils?
Stephen
- Original Message -
From: "Phil Steitz" <[EMAIL PROTECTED]>
> Stephen Colebourne wrote:
> > I don't have as strong reservations as you. I would suggest that the
test
> > should assume that the iterator o
> from:Phil Steitz <[EMAIL PROTECTED]>
> 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 t
Stephen Colebourne wrote:
From: "Phil Steitz" <[EMAIL PROTECTED]>
Grr. Just discovered another wonderful "feature" when implementing a
test for this. Since the algorithm for index(map, i) first tries to
find Integer(i) as a key in the map, if you use a TreeMap to test, this
throws a ClassCastExce
From: "Phil Steitz" <[EMAIL PROTECTED]>
> Grr. Just discovered another wonderful "feature" when implementing a
> test for this. Since the algorithm for index(map, i) first tries to
> find Integer(i) as a key in the map, if you use a TreeMap to test, this
> throws a ClassCastException unless the ke
Phil Steitz wrote:
Hope, Matthew wrote:
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: 21 September 2003 19:10
To: Jakarta Commons Developers List
Subject: Re: [collections] CollectionUtils.index() behavior
OK, I will leave as is, but I personally see this as bad
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: 21 September 2003 19:10
To: Jakarta Commons Developers List
Subject: Re: [collections] CollectionUtils.index() behavior
>OK, I will leave as is, but I personally see this as bad design -- maps
>are not ordered
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
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 -
Fro
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
14 matches
Mail list logo