-
Notifications
You must be signed in to change notification settings - Fork 39
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
Extend StreamRules
Refaster rule collection
#605
Conversation
Looks good. No mutations were possible for these changes. |
6df4877
to
360db11
Compare
Looks good. No mutations were possible for these changes. |
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.
Changes LGTM!
@@ -247,12 +248,13 @@ Optional<S> after(Stream<T> stream, Function<? super T, S> function) { | |||
/** In order to test whether a stream has any element, simply try to find one. */ | |||
static final class StreamIsEmpty<T> { | |||
@BeforeTemplate | |||
boolean before(Stream<T> stream) { | |||
boolean before(Stream<T> stream, Collector<? super T, ?, ? extends Collection<?>> collector) { |
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.
Isn't it nicer to have a separate before template for this one?
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 strong opinion. (Something we could enforce one way or another with automation...)
return Refaster.anyOf( | ||
stream.count() == 0, | ||
stream.count() <= 0, | ||
stream.count() < 1, | ||
stream.findFirst().isEmpty()); | ||
stream.findFirst().isEmpty(), | ||
stream.collect(collector).isEmpty()); |
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.
couldn't you theoretically use a filtering collector though?
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.
Yes! We should add a comment calling out this caveat. I'll add a commit later this morning 👍
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.
Added two more comments. Since this kind of is rare (and since we rewrite top-level filtering
collectors to a regular filter
step), I think this is an acceptable limitation for now.
360db11
to
db9d36e
Compare
Looks good. No mutations were possible for these changes. |
2 similar comments
Looks good. No mutations were possible for these changes. |
Looks good. No mutations were possible for these changes. |
ebf5131
to
997eb0f
Compare
Looks good. No mutations were possible for these changes. |
👍 |
All changes suggested by SonarCloud's `java:s4034` rule, as well as the examples mentioned in openrewrite/rewrite#2984 are now covered. (In a number of cases through composition of more generic rules.) See https://rules.sonarsource.com/java/RSPEC-4034
997eb0f
to
70b4554
Compare
Looks good. No mutations were possible for these changes. |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
All changes suggested by SonarCloud's `java:s4034` rule, as well as the examples mentioned in openrewrite/rewrite#2984 are now covered. (In a number of cases through composition of more generic rules.) See https://rules.sonarsource.com/java/RSPEC-4034
Suggested commit message: