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...

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 😕

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.

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.

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

The solution here is probably https://github.com/Kotlin/KEEP/issues/348

Yes, but when will we get them 😅 😅

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...