On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <d...@openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to 
> `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the 
> `List` interface by providing a more flexible way to find the index of an 
> element. Currently, the `indexOf` and `lastIndexOf` methods only accept an 
> object as a parameter. This limits the flexibility of these methods as they 
> can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing 
> users to define a condition that the desired element must meet. This would 
> provide a more flexible and powerful way to find the index of an element in a 
> list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` 
> interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` 
> interface.
> 3. Implemented these methods in all non-abstract classes that implement the 
> `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and 
> do not introduce any regressions. The test cases cover a variety of scenarios 
> to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose 
> approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and 
> flexibility of the `List` interface, making it more powerful and 
> user-friendly. I look forward to your feedback and am open to making any 
> necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

currently awaiting for initial issue triage to complete

side note: looks like this code have been reformated and some unused imports 
has been reformated. jdk compiles and works just fine, so i guess its not a big 
deal

> Won't this make some calls ambiguous? For example, passing `null`:
> 
> ```java
> List<String> l;
> l.indexOf(""); // Fine
> l.indexOf(null); // Now fails to compile
> ```
> 
> Edit: I'm not a reviewer, but I decided to point this out.

I`ve tested it. Now calling indexOf with null as literal calls 
indexOf(Predicate) instead, as Predicate is lower in class hierarchy than 
Object (ofc it does not apply to varibles that store null, those works just as 
usual)

If you want to call indexOf(Object) instead, you will have to cast null to 
desired type manually

> ```java
> List<String> l;
> l.indexOf(""); // Fine
> l.indexOf((String)null); // Will invoke indexOf(Object)
> ```

Question to reviewers: what do you think would be the best way to handle issue 
discussed above?

PS: converted PR to draft untill the issue is resolved

PPS: The idea I came up with is to possibly rename indexOf(Predicate) to 
something like findIndex(Predicate) or indexOfMatching(Predicate) as a way to 
both avoid unexpected behaviour and preserve source compatibility

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2038490998
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2038506989
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2045522079
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046196342

Reply via email to