-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Java: Make JumpStmt
a proper superclass
#8582
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
Java: Make JumpStmt
a proper superclass
#8582
Conversation
@@ -0,0 +1,4 @@ | |||
--- | |||
category: fix |
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.
Not really a "fix", but the other categories do not seem to fit much better either. Maybe it should be "feature"?
ec5d537
to
a93b4ed
Compare
Thanks for the feedback; have addressed it and force pushed the 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.
Generally looks good to me, but we should avoid making JumpStmt
an abstract
class.
@@ -557,13 +557,7 @@ class ThrowStmt extends Stmt, @throwstmt { | |||
} | |||
|
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.
We generally try to avoid exposing public abstract
classes like this, since subclassing using extends
can lead to surprising results. It is better to define the union type explicitly:
private class JumpStmt_ = @breakstmt or @yieldstmt or @continuestmt; | |
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.
Good point, thanks! I have implemented your suggestion manually, and added a small comment explaining the rationale; hopefully that is alright.
A bit unrelated, but I have created a #8713 to discuss making implementing abstract classes less error-prone.
Public abstract classes can be error-prone, when users unintentionally implement a new subclass instead of refining the set of existing subclasses.
Resolves #8569