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
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],
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
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 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 order of
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
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 ClassCastException
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 the
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
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 keys in the
-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
Not so
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 -
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
13 matches
Mail list logo
