Skip to content

Conversation

shs96c
Copy link
Member

@shs96c shs96c commented Oct 19, 2021

Why do this? The main reason is to support frameworks that wish to
extend Selenium, but return their own sub-types of WebElement from
findBy.

findElement can already be overridden using co-variant return types,
but the List<WebElement> returned by findElements could not be
overridden as easily. This signature change allows that.

With this change in place, subclasses of WebDriver can now do
something like this, without there being compilation issues:

public interface Special extends WebDriver {
    SpecialElement findElement(By locator);
    List<Specialelement> findElements(By locator);
}

Compiling the entire java code base suggests that this is a safe
change to make -- no tests or other calls sites needed to be modified
in order for this change to work.

Thanks for contributing to Selenium!
A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines.
Avoid large PRs, help reviewers by making them as simple and short as possible.

Description

Motivation and Context

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • I have read the contributing document.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@shs96c shs96c added the C-java Java Bindings label Oct 19, 2021
@shs96c shs96c force-pushed the generic-find-elements branch from d0a70bb to 385a893 Compare October 19, 2021 12:30
* @see org.openqa.selenium.By
*/
List<WebElement> findElements(By by);
<T extends WebElement> List<T> findElements(By by);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should a similar change be done for findElement?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, because we can rely on co-variant return types there. The only signature that needs to change is findElements, and that's because we want to return a typed list, and List<WebElement> is not the same as List<? extends WebElement> in generics.

titusfortner
titusfortner previously approved these changes Oct 20, 2021
Copy link
Member

@titusfortner titusfortner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't see any backward compatibility issues, then we should merge it. The sooner we release this, the sooner the appium devs can use it for their next release.

diemol
diemol previously approved these changes Oct 20, 2021
*/
@Override
List<WebElement> findElements(By by);
<T extends WebElement> List<T> findElements(By by);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change should also probably go into the corresponding method of the abstract By class?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I'll do that too.

Why do this? The main reason is to support frameworks that wish to
extend Selenium, but return their own sub-types of `WebElement` from
`findBy`.

`findElement` can already be overridden using co-variant return types,
but the `List<WebElement>` returned by `findElements` could not be
overridden as easily. This signature change allows that.

With this change in place, subclasses of WebDriver can now do
something like this, without there being compilation issues:

```
public interface Special extends WebDriver {
    SpecialElement findElement(By locator);
    List<Specialelement> findElements(By locator);
}
```

Compiling the entire java code base suggests that this is a safe
change to make -- no tests or other calls sites needed to be modified
in order for this change to work.
@shs96c shs96c dismissed stale reviews from diemol, titusfortner, and mykola-mokhnach via d9816da October 25, 2021 09:33
@shs96c shs96c force-pushed the generic-find-elements branch from 385a893 to d9816da Compare October 25, 2021 09:33
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@shs96c
Copy link
Member Author

shs96c commented Oct 26, 2021

While this change “only” causes some warnings in Java (which can be easily suppressed), this change will break Kotlin code, and that’s far from ideal.

Perhaps we need to hold off on this until we come up with a way to make this work smoothly for Kotlin users.

@diemol
Copy link
Member

diemol commented Nov 3, 2021

After chatting with @mykola-mokhnach and checking the linked PR, the Appium team does not need this anymore.

@diemol diemol closed this Nov 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

C-java Java Bindings

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants