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

Deprecated state getter setters in behavior builder and its IMPL #1541

Merged

Conversation

ayushprashar
Copy link
Contributor

@ayushprashar ayushprashar commented Aug 21, 2018

Pull Request Checklist

  • Have you read through the contributor guidelines?
  • Have you signed the Lightbend CLA?
  • Have you added copyright headers to new files?
  • Have you updated the documentation?
  • Have you added tests for any changed functionality?

Fixes

Fixes #1330

Purpose

What does this PR do?
This PR deprecated the setState and getState methods of the behaviour builder and its impl.

Background Context

Why did you take this approach?

References

Are there any relevant issues / PRs / mailing lists discussions?
#1302

@ayushprashar
Copy link
Contributor Author

@renatocaval @erip @TimMoore
Had to delete my previous PR due to some issues. Kindly continue on this one.

Copy link
Contributor

@marcospereira marcospereira left a comment

Choose a reason for hiding this comment

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

Thank you, @ayushprashar.

We should just fill the deprecated message and since, but besides that, it looks good to me.

@@ -211,8 +211,10 @@ abstract class PersistentEntity[Command, Event, State] {
private var commandHandlers: Map[Class[_ <: Command], JBiFunction[_ <: Command, CommandContext[Any], Persist[_ <: Event]]] =
cmdHandlers

@scala.deprecated
Copy link
Contributor

Choose a reason for hiding this comment

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

Add message and since to the deprecation annotations. For example:

@deprecated("A message explaining why this method was deprecated", since = "1.5.0")

This way, the compiler can give users better warning messages and directions about how to avoid the deprecated APIs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@marcospereira Done! Please let me know for any further changes.

@ayushprashar
Copy link
Contributor Author

@renatocaval @marcospereira
Let me know for any other changes, if at all.

@octonato
Copy link
Member

@ayushprashar, yeah, maybe one more small thing:

I was thinking about the sentence on the deprecation message:
"The method is deprecated because it was deemed unproductive"

I don't know if unproductive is the right term here.

If I read back the comment that triggered issue #1330, in #1302 (comment) I believe that the main reason for deprecating it is that we don't really have a reason for this to exist.

It's probably a letfover from some previous refactoring.

Maybe we should simply say that the method is The method is deprecated because it was deemed obsolete.

@ayushprashar
Copy link
Contributor Author

Very well @renatocaval. Agreed.

@ayushprashar
Copy link
Contributor Author

Done! @renatocaval @marcospereira
PS: I don't have the write access to merge this, if you guys could help with that.

@octonato octonato merged commit ed6ab7c into lagom:master Aug 22, 2018
@octonato
Copy link
Member

Thanks for this @ayushprashar. And for the patience. :-)

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.

None yet

3 participants