Skip to content
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

Have FluxFlatMapUsage better handle nested Publishers #224

Merged
merged 3 commits into from
Oct 26, 2022

Conversation

eliashenko
Copy link
Contributor

@eliashenko eliashenko commented Sep 6, 2022

Introduce check for calling flatMap() on Flux or Flux

@eliashenko eliashenko force-pushed the eliashenko/PRP-12517 branch 2 times, most recently from 07c7915 to dcd5811 Compare September 8, 2022 13:14
Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

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

Tnx for this! Indeed important that for GroupedFlux we don't default to suggesting concatMap. Left some thoughts :)

Comment on lines 75 to 101
if (NestedTypesUtils.isSameTypeNested(FLUX, tree, state)) {
return buildDescription(tree)
.addFix(maxConcurrencyFix)
.setMessage(
"`Flux#flatMap` and `Flux#flatMapSequential` have subtle semantics;"
+ " please explicitly specify the desired amount of concurrency")
.build();
}
Copy link
Member

Choose a reason for hiding this comment

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

I guess this rule applies to any nested Publisher, or just when GroupedFlux is the outer type. If the idea is that users will generally want to deal with a Flux<Publisher> by performing parallel subscriptions, then generalizing to the former might be nicer. Not sure.

^ In either case we shouldn't reuse NestedTypesUtils.isSameTypeNested, but IMHO that's not a bad thing; I suspect that a more general matcher for types of T<A, B, C, ...> may be more useful. (But perhaps that's out of scope for this PR 😄.)

"`Flux#flatMap` and `Flux#flatMapSequential` have subtle semantics;"
+ " please explicitly specify the desired amount of concurrency")
.build();
}

return buildDescription(tree)
.addFix(SuggestedFixes.renameMethodInvocation(tree, "concatMap", state))
Copy link
Member

Choose a reason for hiding this comment

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

Rather than omitting this fix, how about we make it the second fix? That would simplify the code and allow us to make fewer assumptions. (In this case patching will rewrite the code to use the bounded-concurrency flatMap, as desired.)

(In this case we wouldn't need a custom message above.)

Copy link
Member

Choose a reason for hiding this comment

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

^ I'll push a proposal for this. Of course still open to discuss the alternative!

@@ -33,6 +33,10 @@ void identification() {
" Flux.just(1).flatMapSequential(Flux::just);",
" // BUG: Diagnostic contains:",
" Flux.just(1).<String>flatMapSequential(i -> Flux.just(String.valueOf(i)));",
" // BUG: Diagnostic contains:",
" Flux.just(\"test_1\", \"test\").groupBy(String::length).flatMap(Flux::just);",
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
" Flux.just(\"test_1\", \"test\").groupBy(String::length).flatMap(Flux::just);",
" Flux.just(1, 2).groupBy(i -> i).flatMap(Flux::just);",

The other tests are using ints so I suggest to do the same here :).

import com.sun.tools.javac.util.List;

/** Utility class that can be used to identify nesting of the same type. */
public final class NestedTypesUtils {
Copy link
Member

Choose a reason for hiding this comment

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

We don't really use Utils as suffix for Util classes, so pushing something.

Final name TBD, maybe we can generalize this 👀.

Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

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

Rebased and added a commit with a proposal. Note that most of the changes are also part of #234; the idea is to merge that PR first.

" void m() {",
" Flux.just(1).concatMap(Flux::just);",
" Flux.just(1).concatMap(Flux::just);",
" Flux.just(1, 2).groupBy(i -> i).flatMap(Flux::just, MAX_CONCURRENCY);",
" Flux.just(1, 2).groupBy(i -> i).flatMapSequential(Flux::just, MAX_CONCURRENCY);",
" }",
"}")
.doTest();
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
.doTest();
.doTest(TEXT_MATCH);

@rickie this is another one of those things for which we should introduce a check.

"`Flux#flatMap` and `Flux#flatMapSequential` have subtle semantics;"
+ " please explicitly specify the desired amount of concurrency")
.build();
}

return buildDescription(tree)
.addFix(SuggestedFixes.renameMethodInvocation(tree, "concatMap", state))
Copy link
Member

Choose a reason for hiding this comment

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

^ I'll push a proposal for this. Of course still open to discuss the alternative!

Comment on lines 11 to 13
/** Utility class that can be used to identify nesting of the same type. */
public final class NestedTypes {
private NestedTypes() {}
Copy link
Member

Choose a reason for hiding this comment

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

This approach seems rather niche, as more complex types wouldn't be supported. I think I found another approach. Will push a proposal to this PR, but since it's quite some code, the idea is that we'll merge those changes in a separate PR first, then rebase this PR.

NB: We should get into the habit of writing tests also for these utility classes.

@Stephan202 Stephan202 added this to the 0.5.0 milestone Oct 15, 2022
@Stephan202 Stephan202 force-pushed the eliashenko/PRP-12517 branch from 9b4006b to 6a1085f Compare October 15, 2022 13:47
Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

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

I squashed the changes and rebased the PR on top of #234. The original state of the branch was tagged as tmp/eliashenko-PRP-12517-2202-10-15. No further suggestions from my side; I like this proposal!

Suggested commit message:

Have `FluxFlatMapUsage` better handle nested `Publisher`s (#224)

@Stephan202 Stephan202 force-pushed the eliashenko/PRP-12517 branch from 6a1085f to c110c92 Compare October 21, 2022 22:35
@Stephan202 Stephan202 changed the base branch from master to sschroevers/introduce-moretypes October 21, 2022 22:36
@Stephan202 Stephan202 force-pushed the sschroevers/introduce-moretypes branch from df41c50 to 79ee60b Compare October 25, 2022 15:07
Base automatically changed from sschroevers/introduce-moretypes to master October 25, 2022 15:13
@rickie rickie force-pushed the eliashenko/PRP-12517 branch from c110c92 to 743c5a0 Compare October 26, 2022 08:28
@rickie
Copy link
Member

rickie commented Oct 26, 2022

Rebased and resolved conflicts.

Copy link
Member

@rickie rickie left a comment

Choose a reason for hiding this comment

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

Really nice addition. Congrats on your first contribution 🚀 !

Sorry for taking a long time to review the MoreTypes PR 😬.

@rickie rickie changed the title Introduce check for calling flatMap() on Flux<GroupedFlux> Have FluxFlatMapUsage better handle nested Publishers Oct 26, 2022
@rickie rickie merged commit 2196bbd into master Oct 26, 2022
@rickie rickie deleted the eliashenko/PRP-12517 branch October 26, 2022 08:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants