kvr000 commented on code in PR #1270:
URL: https://github.com/apache/commons-lang/pull/1270#discussion_r1759171390
##########
src/main/java/org/apache/commons/lang3/ArrayUtils.java:
##########
@@ -1432,6 +1432,115 @@ public static <T> T arraycopy(final T source, final int
sourcePos, final T dest,
return dest;
}
+ /**
+ * Searches element in array sorted by key.
+ *
+ * @param array
+ * array sorted by key field
+ * @param key
+ * key to search for
+ * @param keyExtractor
+ * function to extract key from element
+ * @param comparator
+ * comparator for keys
+ *
+ * @return
+ * index of the search key, if it is contained in the array within
specified range; otherwise,
+ * (-first_greater - 1). The first_greater is the index of lowest
greater element in the list - if all elements
+ * are lower, the first_greater is defined as toIndex.
Review Comment:
@sebbASF @garydgregory :
> In the case of the 'Arrays' method, the entire entry is matched, so to
some extent it does not matter which index is returned. That is not the case
where a partial key is used, so I think in the user will often want to know all
the matches.
In my particular case, I have list of GPS locations sorted by time and track
distance, with distance unchanged if there was no move (causing duplicates).
One use case is to find point for particular distance and if there are
duplicates, I want the result to be predictable (here last but can be first in
different use cases). If the result is unpredictable, it will lead to
different results based on initial conditions for the search. I don't care
about whole range, though I can imagine someone would appreciate such function
with added complexity.
> Sudden thought: surely key extraction can take place in the Comparator, so
why is this method needed at all?
No, unless we're able to construct the full object which is not always
possible - note that `Comparator` takes two arguments of the same type. It is
technically achievable with hacking and casting one argument to `T` and the
other one to `K`, relying on internal implementation passing the arguments in
expected order.
@garydgregory :
> Please revert the First/Last APIs.
For the reasons above, I want to keep those as they better match intended
use case. I think we actually don't need original unpredictable
`binarySearch()` .
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
