-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
Make SearchContext.findElements
have a generic return type
#9953
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
d0a70bb
to
385a893
Compare
* @see org.openqa.selenium.By | ||
*/ | ||
List<WebElement> findElements(By by); | ||
<T extends WebElement> List<T> findElements(By by); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
*/ | ||
@Override | ||
List<WebElement> findElements(By by); | ||
<T extends WebElement> List<T> findElements(By by); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
d9816da
385a893
to
d9816da
Compare
Kudos, SonarCloud Quality Gate passed! |
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. |
After chatting with @mykola-mokhnach and checking the linked PR, the Appium team does not need this anymore. |
Why do this? The main reason is to support frameworks that wish to
extend Selenium, but return their own sub-types of
WebElement
fromfindBy
.findElement
can already be overridden using co-variant return types,but the
List<WebElement>
returned byfindElements
could not beoverridden 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:
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
Checklist