I wonder if it would be a good idea to have an option that optics generates it's own `object` (like ...

# arrow

[dave08]

I wonder if it would be a good idea to have an option that optics generates it's own object (like possibly in the original package + .optics, or for Person have PersonOptic) to put all the extension functions on... on one hand, it's handy to have them all extend the class it deals with, but it adds lots of boilerplate to entity classes... adding companion object to each one with no real need for it in the entity itself... and when dealing with large sealed class hierarchies, it's VERY messy...

[simon.vergauwen]

It would be more ideal to just be able to inject a companion object when it's missing, just like KotlinX Serialization does but for that you need access to the compiler through plugins 🤕

We've been postponing working much on this ever since compiler plugins were announced in 2018/19 😕

[dave08]

True, that's probably better... but compiler plugins are sooo much harder to manage... my proposition is very simple, and probably makes it more pleasant to work with optics for now.

[simon.vergauwen]

Currently compiler plugins are still tedious, but can be manageable like kotest which installs it automatically through a Gradle plugin, but it would require a IDEA plugin 😭

The work for plugins is still on-going, but will most likely take longer than context receivers. We're considering an Arrow IDEA plugin, and then perhaps it's more feasible but that would require a lot of work/personal-time investment as well.

[simon.vergauwen]

The problem with KSP is that it also doesn't allow global configuration from Gradle afaik, so you could not say from Gradle to use a different strategy like PersonOptic.

[dave08]

It seems that you can... they do it: https://www.komapper.org/docs/reference/annotation-processing/#options

[dave08]

https://github.com/komapper/komapper/blob/e988b4944061ea3f45a5bf1002d4f28363a863af[…]pper-processor/src/main/kotlin/org/komapper/processor/Config.kt

[dave08]

With such settings, one might even be able to avoid all those annotations... just by telling gradle which packages to process... usually entities are regrouped in certain packages.

[stojan]

The solution here is probably

https://github.com/Kotlin/KEEP/issues/348

[simon.vergauwen]

Yes, but when will we get them 😅 😅

[dave08]

Yeah... like the LOOOONG wait for context receivers... 🙃. Meanwhile Arrow 2.0 (or at least 1.2.0) can come out way before, and it might be nice to already have some way to make optics cleaner to use...