<@U4UGS5FC7> <@U0RM4EPC7> i noticed that `lenses` ...

# arrow-meta

[rt]

@raulraja @simon.vergauwen i noticed that lenses plugin in meta is commented out, not sure what the reason is. i've experimented with adding support for type parameters on case classes (wrt lenses):
usage https://github.com/tkroman/poptix/blob/master/poptix-gradle-plugin-test/src/main/kotlin/com/tkroman/poptix/PoptixExample.kt#L13
src https://github.com/tkroman/poptix/blob/master/poptix-gradle-plugin/src/main/kotlin/com/tkroman/poptix/PoptixTransformation.kt#L85
does this look like something useful for the mainline? i'm not really confident about the quality of implementation but would love to help out (with proper guidance) if you would accept this contribution

[rt]

(tagged people from git blame, not sure who's the right contact on this)

[raulraja]

it’s incomplete and broken and we found a better way to implement it but we are waiting for typed quotes which @bloder is working on

[rt]

is it public yet? would love to follow the progress

[raulraja]

no code yet until we have typed quotes, but typed quotes is in a branch

[raulraja]

the approach for optics discussed is to generate only those used at call sites unless you turn on library mode which generates optics for all data and sealed classes in the module or selectively via annotations

[bloder]

Hi! You can follow the progress of typed quotes here: https://github.com/arrow-kt/arrow-meta/pull/679

[raulraja]

This is going to be proposed as a feature for all data classes for the lang in a KEEP so we want it to work as it would work in vanilla kotlin with synth methods

[rt]

yes, that would make a lot of sense especially for the type-parametrized ones. plus they could be cached so that if i make a lense for Foo<A>, and then instantiate it for eg String , I won't produce a lot of garbage (literal and figurative) on every call-site

[raulraja]

right the current wrapped encoding is not ideal either but serves us as a way to get a quick prototype but in a compiler we can optimize them with field access instead of using copy etc.

[rt]

wow, it's just enjoyable to witness how your [ambitious] plans come to life for the good of whole language. tbh after all the scala infighting using kotlin feels good not in the least thanks to how much integrity this community has. offtopic rant off

[raulraja]

hahaah thanks, for what is worth we are gonna attempt to make Scala better with the lessons learned in Kotlin too.