I'm currently working with a lot of DSL and thus b...

# language-evolution

[Leon K]

I'm currently working with a lot of DSL and thus builder-classes, which currently are relatively cumbersome to implement when you want to otherwise work with immutable data-classes. I was thinking about how one could optimize this...
serveral solutions come to mind. there is autoDSL, a library based on annotation processing that can automatically generate a dsl-style builder for your classes, which is simmilar to what i want, but is rather inelegant, and a library needing kapt - hurting compile-times

What would you think about some kind of language-feature that allows for easier building of immutable (data)-classes, like some kind of buildable class modifier?

I could imagine it being a way to specify that a data-class has some buildable fields, that are, as long as the class has not been built, mutable (and also might include building-functions, that are only present whilst the object hasn't been built.
the modifier could then introduce a new method create which turns the buildable class-instance into the normal, immutable data-class instance that you would then use everywhere.

this would, in a way, be a way of combining a builder class together with it's fully built, immutable version. for simple data-container-classes, this could be really practical
any thoughts?

[Leon K]

There would be some significant problems with this way of implementing it, for example... how would you handle the classes "not-yet-built" vs "fully-built" state? would it be some kind of type-modifier similar to ??

also, would this be worth it and even desirable? it would really only make sense for truly immutable, data-container-only classes that don't contain any side-effecty functions

[Hanno]

Is it not sufficient to just use the data class constructor with named Arguments?

[Leon K]

not when
a) you're using a DSL as a config-file, simmilar to what gradle does
b) you're using a DSL in general, see the ktor webserver for a prime example
c) you're doing things in-between or building a very complex class over multiple functions

[Hanno]

Hmmm maybe i don't have enough experience but i can't agree with a) and b), because the only significant difference for me is the braces...For c) i would only write dsl stuff for the very complex class and the property classes with data classes. As for a) gradle is also not pure dsl, some parts like local properties are regular code as well. Could you maybe give an example??

[jimn]

it seems to me that some additional operators and permissions to overload more operators and add infix arities would go a long way here. It seems like one of the halting points along this line of discussion is that operator precedence outside of comfortable example territory

[jimn]

infix with 0 arity would be handy, as would matching confix operators e.g. "[", "]" as well as suspending backtick requirements for a given block

[jimn]

there are a lot of companion object hacks to manufacture builders without coloring too far out of the lines like java requires for builders

[raulraja]

You can build this with a compiler plugin and not be dependent on kapt, just generate the builders for each annotated class in the analysis phase. Arrow Meta can do what Kapt does working with Quotes over the PSI tree and produce new files that are considered prior to type checking.