dalexander
10/09/2020, 2:34 PMDataClass.from(internalRepresentation)
without requiring developers to hand write the from
adapter. I would do this using annotation processing but there's data missing in the kapt Java stubs (default values). I want to eventually add some validation as well, but generating adapters is the first step.
1) How safe would Arrow Meta would be for doing this for production? ie. How likely are there to be breaking API changes (especially non-trivial ones). I know there's some compiler revision going on right now so there's potentially a lot of uncertainty.
2) Is it reasonable to want to use Arrow Meta/a compiler plugin to do this?
raulraja
10/09/2020, 3:00 PM1) How safe would Arrow Meta would be for doing this for production? ie. How likely are there to be breaking API changes (especially non-trivial ones). I know there’s some compiler revision going on right now so there’s potentially a lot of uncertainty.Arrow meta from here on will follow compiler releases and will release the first stable version when the compiler makes the IR backend non-experimental which also others like Jetpack compose are waiting for. From that point forward as in any compiler plugin they are always tied to the compiler runtime so you also will have to release each time the compiler releases until they provide a public stable API.
2) Is it reasonable to want to use Arrow Meta/a compiler plugin to do this?Yes, you can already use meta to access the precise typechecked info of a data class without the java stubs limitations you find in kapt and use meta to generate new sources or transform the IR tree before code generation.
dalexander
10/09/2020, 3:12 PMraulraja
10/09/2020, 3:32 PMdalexander
10/09/2020, 3:50 PMraulraja
10/09/2020, 8:15 PM