-
Notifications
You must be signed in to change notification settings - Fork 66
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
Suggestion: Add parFlatMapN
#365
Comments
It's a good suggestion! Generally speaking, there is a PR to cats with adding this method already. I've asked about its status, and feel free to vote about naming in that PR! |
(if that PR goes through as flatParMapN, I'm opening a PR to mouse to add an alias that is parFlatMapN 😄 ) |
No worries, I'm the one who opened the PR on cats, and I just changed the function's name ;) |
OK - I think that's me satisfied, I'll close this issue! |
Motivation
I really like
flatMap
.I also really like
parMapN
on tuples.I therefore suspect I'd really love a
parFlatMapN
currently:
what I'd love to have:
Is there another way to accomplish this than
parFlatMapN
Yep, but I think it'd be quite nifty to have it.
The argument against is I suspect that you can just do .parMapN(..).flatten - it's not that much more code to look at - but wouldn't the same argument apply to most flatMap operations (you could just do .map(...).flatten)?
It came up in a $DAYJOB example that looked not-really-but-kind-of-sort-of like this (using cats-effects IO here for the sake of the example)
... which, yes, in this simplified could be refactored this to be more legible in a myriad ways. But, I still think parFlatMapN would have made it more obvious than a flatten (especially because I'm already using .flatten for the List[Option[A]]` inside the parMapN, so there's a bit of mental gymnastics people have to do to realize which thing is being flattened and why)
The text was updated successfully, but these errors were encountered: