You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
IntelliJ (and probably other editors) support editor-fold comments to collapse stuff that probably is not so interesting to look at to get an overview: https://www.jetbrains.com/guide/java/tips/editor-fold/
In our code, we have generated data classes where when we go into the generated code, we are only really interested in the primary constructor parameter list, to see whats inside the dataclass. All the other stuff (annotations, additional constructors, etc. are not really interesting to look at when everything runs smoothly).
In our case, we have the primary constructor private to prevent code to use non-named parameter constructor calls.
Example:
//<editor-fold desc="not so interesting to look at, please focus on the members">
@JsonSerialize(...)
@JsonDeserialize(...)
@ApiModel
...
//</editor-fold>publicdata classMyGeneratedDataStructure private constructor(
publicvalmember1:Boolean,
publicvalmember2:Boolean,
publicvalmember3:Boolean,
publicvalmember4:String,
publicvalmember5:OtherGeneratedStructure,
//...
) {
//<editor-fold desc="not so interesting to look at, please focus on the members">publicconstructor(
vararg nothing:PleaseDoNotUseNonNamedParameters,
... dozens of parameters
) :this(
... dozens of parameters
) {
... hundreds of lines of parameters
}
//</editor-fold>
}
publicdata classOtherGeneratedStructure ...
This would collapse in the IDE like this:
constructors cannot be extension methods, otherwise I would move the clutter into an extension method to keep the data classes as clean as possible. Also annotations can be quite extensive and they cannot be moved somewhere else, as far as I know
Describe the solution you'd like
Something like this would be nice:
FileSpec
.builder("com.example.model", "models")
.addType(
TypeSpec
.classBuilder("MyGeneratedDataStructure")
.addAnnotation(AnnotationSpec
.builder(...)
.addToFoldGroup("not so interesting to look at, please focus on the members")
.build()
)
.primaryConstructor(
FunSpec
.constructorBuilder()
.addCode(...)
.addToFoldGroup("not so interesting to look at, please focus on the members")
.build()
)
.build(),
)
.build()
Describe alternatives you've considered
Adding the comments as a second step outside of kotlinpoet. This would be rather cumbersome tough
moving the stuff out into a separate file (this works for all the other stuff except constructors and annotations)
The text was updated successfully, but these errors were encountered:
This came up when we were contributing to SwiftPoet, too.
Part of the problem is that we reserve the right to re-arrange the order of members added to a type. Additionally, we might collapse a member into a primary constructor, such as when it forms a primary constructor property. I don't have a good way to reconcile this behavior with regions.
For non-collapsing members we could group by region and then perform our ordering. But that also might change the initialization order of default values and break compilation.
I don't see a clear path to supporting this, unfortunately.
Is your feature request related to a problem? Please describe.
IntelliJ (and probably other editors) support
editor-fold
comments to collapse stuff that probably is not so interesting to look at to get an overview: https://www.jetbrains.com/guide/java/tips/editor-fold/In our code, we have generated data classes where when we go into the generated code, we are only really interested in the primary constructor parameter list, to see whats inside the dataclass. All the other stuff (annotations, additional constructors, etc. are not really interesting to look at when everything runs smoothly).
In our case, we have the primary constructor private to prevent code to use non-named parameter constructor calls.
Example:
This would collapse in the IDE like this:
constructors cannot be extension methods, otherwise I would move the clutter into an extension method to keep the data classes as clean as possible. Also annotations can be quite extensive and they cannot be moved somewhere else, as far as I know
Describe the solution you'd like
Something like this would be nice:
Describe alternatives you've considered
The text was updated successfully, but these errors were encountered: