Generate constant for types without arguments#14
Open
Almighty-Alpaca wants to merge 2 commits into6thsolution:masterfrom
Open
Generate constant for types without arguments#14Almighty-Alpaca wants to merge 2 commits into6thsolution:masterfrom
Almighty-Alpaca wants to merge 2 commits into6thsolution:masterfrom
Conversation
At the cost of a breaking change unfortunately
Contributor
|
Hi, since we have constant factories, |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In my project I have a sealed class with an empty subtype that I use as default argument in a constructor. For that to work I need a static constant of that type, which I currently have to create myself as a top level field. This PR allows the writer to generate those constants as static const field inside the sealed class.
Edit: I've noticed that my first commit didn't produce correct Dart code, so I've fixed that in the second one. Unfortunately for that I needed to remove the factory method that was previously generated for such subtypes, which is a breaking change. If this isn't acceptable, this could be solved with an optional parameter on the
@Sealed()annotation controlling the code generation. But before I go there, I'll wait for feedback if this is a welcome addition at all here first.Excerpt of generated code: