kotlinpoet icon indicating copy to clipboard operation
kotlinpoet copied to clipboard

Experiment with kotlinpoet without builders

Open jmfayard opened this issue 6 years ago • 4 comments

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

jmfayard avatar Sep 30 '18 17:09 jmfayard

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 avatar Nov 29 '18 18:11 Egorand

@Egorand no problem!

jmfayard avatar Nov 30 '18 11:11 jmfayard

@ergoland actually I can give you more feedback on this: I wrote a Gradle plugin based on Kotlinpoet recentlly. The builders were not a problem once I was into it. If that's the price to make the library compatible with Java, I'm totally happy with it.

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"

jmfayard avatar Nov 30 '18 12:11 jmfayard

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. inline properties are another example - what you really do when you declare a property as inline is making both of its accessors inline, hence with KotlinPoet you'll have to mark the getter and the setter with KModifier.INLINE, and in that case we'll emit the property with the inline modifier.

Egorand avatar Nov 30 '18 14:11 Egorand