Is there a shortcut to create a lens for a generic...

# arrow

[rt]

Is there a shortcut to create a lens for a generic class? I guess I’m looking for plens, but I’d like to avoid writing everything manually

[raulraja]

There is polymorphic lenses but can’t be projected over generics afaik

[raulraja]

did you try to annotate a generic ADT with @optics ?

[rt]

I did but I still don't know how to summon them via dsl:

import arrow.optics.optics
import arrow.optics.dsl.*

@optics data class G<A>(val x: A) {
    companion object
}
@optics data class X(val x: Int) {
    companion object
}
fun main() {
    val gx = G<X>.x.x
}

fails with

e: G$$optics.kt: (7, 112): One type argument expected for class G<A>

where generated code is e.g.

inline val `G`.Companion.iso: arrow.optics.Iso<`G`, `A`> inline get()= arrow.optics.Iso(
  get = { g: `G` -> g.x },
  reverseGet = { `G`(it) }
)

Should i file an issue?

[rt]

Or is this unsupported by design?

[rt]

OTOH this works:

data class G<A>(val a: A) {
    companion object {
        fun <A> a(): Lens<G<A>, A> = Lens(
            { it.a },
            { ga, xx -> ga.copy(a = xx) }
        )
    }
}
@optics data class X(val x: Int) {
    companion object
}
fun main() {
    assert(G.a<X>().compose(X.x).get(G(X(1))) == 1)
}

so i guess i'm OK since i can type in the boilerplate once (for the "higher-kinded" adt). I mean, once per every field, which is still unfortunate but i guess meh, I can live with that 🙂

[raulraja]

that is that the current annotator is not supporting polymorphism correctly

[raulraja]

but also we are not spending time there because we are gonna develop auto optics as the plugin DSL with meta

[raulraja]

that is optics are projected as consumed over any algebraic datatypes regardless of generics

[rt]

I see. Thanks for the help anyway!

[raulraja]

so we are abandoning those kapt processors and killing them in the next iterations right before 1.0

[raulraja]

but if you want to fix it we still accept patches

[rt]

Oh, so meta is going to work without kapt at all? that's nice to hear

[rt]

You actually told this to me in person @ kotlinconf but looks like my memory isn't that good 😄

[rt]

but i remember being excited about it for sure

[simon.vergauwen]

Yes, the problem lies with kapt and its complexity.
This is something I’d really love to support using compiler plugins!

[raulraja]

Meta does not need kapt because already has the types, we just haven’t gotten to the optics plugin yet since we have been busy with all others and stabilising meta with the compiler