Experiment with kotlinpoet without builders#487
Experiment with kotlinpoet without builders#487jmfayard wants to merge 1 commit intosquare:mainfrom jmfayard:jmfayard.builder-free
Conversation
I thought the builder pattern was mostly useless in kotlin, which has named parameters, default values and works well with an immutable functional style like the one used by kotlin poet. This is an experiment with the kotlinpoet codebase to test this hypothesis. Of course I don't advocate removing the builders apis, that would be bad for people calling kotlinpoet from java or with an existing code base. I'm only adding stuff, and delegating to those builders, even adding a configuration lambda for all the corner cases where a builder can be useful I modified the examples in the README to see what the changes would look like
|
We still feel that builders are the most flexible solution for KotlinPoet API, and hosting two different API styles in the library core would make it hard to maintain and consume. Nevertheless, I'm happy to keep this PR around in case someone borrows your idea to build their own wrapper on top of KotlinPoet API, if this is what fits certain use-cases better. Thanks for building this, and sorry for taking that long to respond. |
|
@Egorand no problem! |
|
@ErgoLand actually I can give you more feedback on this: I wrote a Gradle plugin based on Kotlinpoet recentlly. On the other hand, I don't like what you need to do to declare a simple class with properties declared in the constructor. IMHO Kotlinpoet nailed only the second half of principle: "Make simple things easy and make complicated things possible" |
|
Thanks for the feedback! The philosophy of KotlinPoet is that we don't model things that are just Kotlin's syntactic sugar, instead we require the full model to be flexible in how we emit it. Primary constructor properties are an example of this. |
I thought the builder pattern was mostly useless in kotlin,
which has named parameters, default values
and works well with an immutable functional style like the one used by kotlinpoet.
This is an experiment with the kotlinpoet codebase to test this hypothesis.
Of course I don't advocate removing the builders apis,
that would be bad for people calling kotlinpoet from java or with an existing code base.
I'm only adding stuff, just enough to see how that would like for the README,
I'm delegating the actual work to the builders.
even adding a configuration lambda for all the corner cases where a builder can be useful
I modified the examples in the README to see what the changes would look like