|
Quick Lists
|
|
Bug ID:
|
6438838
|
|
Votes
|
3
|
|
Synopsis
|
(coll) Add Arrays.in(T e, T... elements)
|
|
Category
|
java:classes_util
|
|
Reported Against
|
|
|
Release Fixed
|
|
|
State
|
5-Cause Known,
request for enhancement
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
|
|
Submit Date
|
14-JUN-2006
|
|
Description
|
A DESCRIPTION OF THE REQUEST :
Create a method to verify if an element is in a arrays of elements, like Collection.contains(). The code can be:
public static <T> boolean in(T e, T ... elements) {
//An element wasnīt in an empty array
if (elements==null || elements.length==0) {
return false;
}
for (T t : elements) {
if ( (e==null && t==null) || (t!=null && t.equals(e))) {
return true;
}
}
return false;
}
Example use code:
String[] names = {"Jose", "Joao", "Maria"};
if (java.util.Arrays.in("Jose", names) {
//do something
}
Itīs can be modified to create an indexOf() instead.
JUSTIFICATION :
Some times we need to verify if an element is in a array of elements without sort it. The java.util.Arrays class provide method to search the element with binarySearch, but in search the array must be sorted.
Posted Date : 2006-06-14 22:24:29.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
Doesn't really seem very compelling.
Does this feature "pull its weight"?
What about
Arrays.asList(a).contains(x)
Probably will close as Will Not Fix.
Posted Date : 2006-06-14 23:26:57.0
From an SDN comment:
"The main objection to Arrays.asList(a).contains(x) is that it doesn't work on arrays of primitive types. (Even worse, it doesn't give an error in this case, it just fails silently.)
In addtion, Arrays.in() or Arrays.contains() would be more readable. I have wanted this feature several times."
The failure to work with primitive arrays is a good point.
The name "contains" seems more compelling than "in" for cognitive compatibility
with the Collection class.
Posted Date : 2006-09-03 02:52:40.0
Jason writes, very reasonably:
"I would think indexOf and lastIndexOf operations would be more useful than a contains operation. Contains can be determined by checking the returned index as being non negative."
More generally, since an array can be regarded as a fixed-length List,
we could go through all of the List methods, and implement the usual
8 static methods in Arrays for every List operation that does not already
have an array equivalent or an Arrays set of static methods, and does not
change the length of the List.
If we do that, the obvious course of action is to add 3 sets of overloadings:
contains
indexOf
lastIndexOf
Other methods, such as hashCode, already have such sets of overloadings.
We should avoid doing anything for e.g. add, clear, remove,
since, unlike the reading methods the expected semantics are unclear
(return a new modified array?) and it would encourage the writing of O(N*N)
algorithms for O(N) problems.
Posted Date : 2006-09-23 21:49:35.0
|
|
Comments
|
Submitted On 01-SEP-2006
axlrosen
The main objection to Arrays.asList(a).contains(x) is that it doesn't work on arrays of primitive types. (Even worse, it doesn't give an error in this case, it just fails silently.)
In addtion, Arrays.in() or Arrays.contains() would be more readable. I have wanted this feature several times.
Submitted On 22-SEP-2006
Jason-Mehrens
I would think indexOf and lastIndexOf operations would be more useful than a contains operation. Contains can be determined by checking the returned index as being non negative.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |