-
Notifications
You must be signed in to change notification settings - Fork 289
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
Simplify Primary Constructor Properties #1734
Comments
Agree with the premise - this is indeed a common use case that currently requires quite a bit of code. But the proposed implementation likely doesn't cover many possible use cases, in particular it's not apparent that the method creates a new primary constructor and attaches it to the If you'd like to send a more fleshed out PR with unit tests that exercise different corner cases, it'd be interesting to see what the final API shape could look like. Something to consider here is that the final version might be more verbose and cumbersome to use than what you already have in your project, simply because it has to be more generic and handle all kinds of use-cases. |
As I become more familiar and confident with KPoet, I'll revisit this and consider leaving a PR. I'm just diving into the project at the moment. In my particular implementation, previous constructor properties would NOT be discarded, they're stored using the |
Fair enough, please do send us a PR! |
When attempting to add primary constructor properties, the solution is rather verbose. Considering our team abuses them, I'd like to propose a separate function that adds strictly a construction property, as can be denoted by the following extension:
fun TypeSpec.Builder.addConstructorProperty(propertySpec: PropertySpec): TypeSpec.Builder
Sample usage:
I actually already implemented this with a hacky little workaround:
Where get/setRetainedValue are used to add instance variables in extensions. Note that it abuses the fact that we can invoke
primaryConstructor
multiple times.I'm sure there are potential use cases where this wouldn't work or would lose values, but it seems stable enough for our use case.
The text was updated successfully, but these errors were encountered: