-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Aliases traverseVoid
/sequenceVoid
and their counterparts
#4682
Conversation
traverseVoid
/sequenceVoid
and their counterparts
@ken1ma, fyi, because you referenced the original inssue in #4661 (comment) |
a1b23d3
to
62a8398
Compare
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.
I think this is a good change. I left a comment about making a stronger recommendation than "consider".
Side note, really "foreach" is what this semantically is, but I think using that name is dangerous given that scala already uses that for side-effecting functions.
Maybe foreachA is also a potential name for this function which is more about the "what" whereas "traverseVoid" is kind of the how...
That said, I think traverseVoid/sequenceVoid are more consistent with cats style and a smaller change from the current situation and give us a clearer path to deprecate the foo_
naming style.
* Alias for `traverseVoid`. | ||
* | ||
* @deprecated this method should be considered as deprecated; | ||
* refrain from using this method and consider switching to `traverseVoid`. |
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.
I wouldn't say consider switching
I would say replaced by traverseVoid
.
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.
@johnynek , thank you for the comment. Before I start making changes, I'd like to make sure we are on the same page. Are you suggesting to rephrase the notice this way (full sentence):
@deprecated this method should be considered as deprecated and replaced by `traverseVoid`.
Is it correct?
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. It is strange to me to deprecate one method, introduce an identical alias but then say "consider using the new version". I think it is more clear to say "please use the new version", or "calls to should be replaced to the new version" or something. Consider implies in my opinion that you may consider it and have a good reason not to, but if we thought there was a good reason not to, we shouldn't deprecate the current name.
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.
Totally makes sense to me, thanks!
62a8398
to
e8d95ee
Compare
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.
Thanks for doing this!
Closes #4611.
The feedback on the original proposal seems generally favorable, therefore here is the PR. Overall, it does the following:
traverseVoid
/sequenceVoid
toFoldable
(converingtraverse_
andsequence_
to aliases for the new methods);nonEmptyTraverseVoid
/nonEmptySequenceVoid
;Parallel
/NonEmptyParallel
;Also it adds some comments to the places that haven't been changed but could be and thereby explaining why.