I looked in the KEEP project and the Kotlin youtra...
# language-proposalsj
jlleitschuh
08/04/2017, 6:04 PMI looked in the KEEP project and the Kotlin youtrack and didn't see anything about this so I figure I'd propose it here:
The current implementation of data classes is really nice, however, creating large data classes can end up creating large constructors. I really like them because they create nicely immutable bundles of data.
In java, the builder pattern is usually utilized when constructors start to get large. However, the builder pattern can become quite clunky quickly, even when written by hand in kotlin.
A developer could use the google auto-value annotation processor but I don't think this works with data classes. Plus its clunky and you have to deal with IDE configuration.
In kotlin named parameters gets around this issue quite nicely because you can selectively specify the fields you want to assign. However, when creating a new instance of a data class in Java you end up with a very large constructor call without any way of knowing what fields you are assigning in the object when looking at the constructor.
My proposal is that data classes get expanded to have a static
builder()đź‘Ť 2
e
elizarov
08/04/2017, 6:06 PMSo what is the problem with AutoValue? Why would you just use it if you need builders from Java?
j
jlleitschuh
08/04/2017, 6:08 PMYou can't apply AutoValue to data classes. Data classes can't be abstract or have abstract methods.
e
elizarov
08/04/2017, 6:10 PMI’d suggest, then, into looking at writing some kind of Kotlin compiler plugin that would generate this kind of builder pattern for Java interop based on some annotation like @JvmBuilder. This would be consistent with how other Jvm-interop annotations work (like @JvmOverloads, etc). This can be pulled off without having to change Kotlin as a language.
đź‘Ť 2
j
jlleitschuh
08/04/2017, 6:12 PMI'd be more than happy to give this a shot. Is this worthy of KEEP or would it be standalone?
Also, is there documentation about writing these compiler plugins?
Setup and API documentation?
e
elizarov
08/04/2017, 6:12 PMI mean, IMHO, working in this direction (plugin vs core change) has much more chances to succeed.
j
jlleitschuh
08/04/2017, 6:13 PMThat makes lots of sense.
e
elizarov
08/04/2017, 6:14 PMNo docs on how to write them, but you can find KEEPs about other plugins, as well as examine how they are written. There is no stable public API, though, so in order to be stable this plugin will have to be contributed into Kotlin source tree
j
jlleitschuh
08/04/2017, 6:18 PMSo you would propose that I merge this into the kotlin source branch instead of trying to host my own project on github?
jlleitschuh
08/04/2017, 6:18 PMOr would you start as an independent project and then try to port it to be merged in the the kotlin code base?
jlleitschuh
08/04/2017, 6:20 PMAlso, is there an example that you can point (link) me to to provide a starting place?
jlleitschuh
08/04/2017, 6:21 PMNvm. Found them
jlleitschuh
08/04/2017, 6:21 PMjlleitschuh
08/04/2017, 7:41 PMGiven everything that I need to setup I'm going to try and do this within the kotlin repository.
v
voddan
08/04/2017, 8:41 PMCan't that be a separate annotator processor? Like auto value, but for kotlin
j
jlleitschuh
08/05/2017, 7:45 PMAnnotation processors can't modify existing classes.
jlleitschuh
08/05/2017, 7:46 PMI'm not having much luck with executing the tests in any of the plugins.
I want to write this using TDD and I can't seem to get my environment setup in such a way that I can write tests. Then write code to test it.
e
elizarov
08/06/2017, 12:19 AMYou’ll need to test from inside debug version of IDEA. Similar to what explained in “Compiling & running” https://github.com/JetBrains/kotlin#compiling-and-running (there is an “IDEA” run configuration to run a second instance of IDEA with your changes to the compiler)
j
jlleitschuh
08/06/2017, 12:22 AM?!?!
Wow! That would kind of make sense.
Can I do TDD easily or will I need to restart the IDE each time I make a change to the plugin?
3 Views