Hey, I’m trying to run the optics compiler plugin ...

# arrow-meta

[Teodor Penkov]

Hey, I’m trying to run the optics compiler plugin with 3rd party generated code. The tricky part is that I don’t have control over the 3rd party generated code so I can’t add @optics annotation to the data classes. I started creating custom plugin based on the optics compiler plugin, so I can look for the classes that I want (e.g.is a data class && it's in specific location ) but that doesn’t seem like the right thing to do.

What would you suggest for the 3rd party code?

pp. I’ve managed to generate some code, but then I stumbled upon errors such as unresolved references etc.

[simon.vergauwen]

Hey @Teodor Penkov,

It would actually be possible to do it for 3rd party code, and I actually once experimented with this and had a working prototype.

This however was abandoned due to the complexity in kapt, but we’d love to pick it up again with Arrow Meta.

[simon.vergauwen]

The first version of the Arrow Optics plugin is just going to be a compiler version of the kapt plugin, but for the V2 Optics plugin we hope to generate the DSL in the compiler FIR which means we can do it for all data classes/sealed classes automatically without impacting the binary.

Only the code that you used will be generated in the binary, unless you’d want to explicitly export it.

[Teodor Penkov]

Sounds amazing.

Am I correct in my understanding that as of now there are 2 possible solutions:
• modify the 3rd party generated code with annotations and run the standard arrow meta optics plugin
• write a custom plugin in order to avoid modifying 3rd party generated code

[Teodor Penkov]

Also would there be any problems if the data classes are nested in other data classes
e.g.

data class A {
  data class Data
}

data class B {
  data class Data
}

In the above example I would want to generate optics for both inner Data classes, but I’m not sure if that wouldn’t run into namespace issues

[simon.vergauwen]

Yes, you understand that correctly. The second step is still being blocked by some feature still being unstable in the compiler, but we hope to be able to start working on that next year.

[simon.vergauwen]

Those classes shouldn’t interfer in the namespace since their fully qualified names should be. package.A.Data and package.B.Data

[Teodor Penkov]

awesome, thanks