<https://medium.com/square-corner-blog/kotlinpoet-1-0-is-here-a3c771c92d47>

# feed

[digitalsanctum]

https://medium.com/square-corner-blog/kotlinpoet-1-0-is-here-a3c771c92d47

[orangy]

omg, these builders… Of course, Java API and all, but…

[orangy]

@egorand seriously, why not an idiomatic DSL?

[orangy]

Found the discussion here: https://github.com/square/kotlinpoet/issues/62

[egorand]

We've had an ongoing discussion about this ever since the early days of KP, and came to the conclusion that builders are still the most flexible approach in our case

[egorand]

Java compat is rather a nice to have

[orangy]

I would be very interested to read a blog post about making the decision here 😉

[egorand]

Yeah, I can try to compile all the pro/cons into a blog post

[egorand]

Anyway, people are successfully building their own DSLs on top of KP, which I think is a win

[orangy]

Agree, I think a DSL can be easily generated with some reflection and KotlinPoet 🙂 But a standard one maintained with the lib to avoid desyncs would still be nice.

[orangy]

Hm, I disagree with @jw here: https://github.com/square/kotlinpoet/issues/435#issuecomment-410533943
DSLs are as composable as builders, you just pass a builder as a reciever instead of a parameter. Same extract function facilities, same reusability. May be I’m missing something important 🤷‍♂️ There is also several mentions of “builders API is more flexible”, but without any real cases when something is doable with builders and not doable (or has other cons) with DSL.

[egorand]

Classic DSLs pretty much confine you to the property definitions, so if FunSpec has a kdoc: CodeBuilder property, you can either set it, or modify it if it's mutable, but you can't expose APIs such as addKdoc(format: String, vararg args: Any?)

[egorand]

Well, you might invent your own syntax to achieve this of course

[jdemeulenaere]

Nice! Now if we could have a Gradle plugin that (when compiling Kotlin files) takes as input the ASTs of the elements annotated by some annotations and allows to generate new FileSpecs, it would be awesome 🙂

[egorand]

That's pretty much what SQLDelight does, only that it compiles SQL into Kotlin

[jmfayard]

I wrote a Gradle plugin with Kotlinpoet. It is good! Builders are not really a problem once you are into it. Some simple things should be easier IMHO like a TypeSpec with properties defined in the constructor

[orangy]

@egorand I didn’t understand this:

Classic DSLs pretty much confine you to the property definitions

you can have a kdoc { … } or whatever signature you want in the DSL. Basically it can look something like this:

type {
    primaryConstructor { 
           kdoc("Creates an instance")
    }
    property<String>("foo", "initExpression()") 
}