<https://medium.com/square-corner-blog/kotlinpoet-...
# feed
o
omg, these builders… Of course, Java API and all, but…
@egorand seriously, why not an idiomatic DSL?
e
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
Java compat is rather a nice to have
o
I would be very interested to read a blog post about making the decision here šŸ˜‰
e
Yeah, I can try to compile all the pro/cons into a blog post
Anyway, people are successfully building their own DSLs on top of KP, which I think is a win
o
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.
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.
e
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?)
Well, you might invent your own syntax to achieve this of course
j
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 šŸ™‚
e
That's pretty much what SQLDelight does, only that it compiles SQL into Kotlin
j
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
o
@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:
Copy code
type {
    primaryConstructor { 
           kdoc("Creates an instance")
    }
    property<String>("foo", "initExpression()") 
}