Document how to get data such as field names/constructors from LightTypeTag

[mdedetrich]

Although its mention in README.md that

izumi-reflect is less powerful than scala-reflect: it does not preserve fields and methods when it's not necessary for equality and subtype checks, it does not preserve code trees, internal compiler data structures, etc.

It would be good to document how to actually achieve this even if its external to izumi-reflect. Specifically if you are already using izumi-reflect , i.e. LightTypeTag and you need to extract data such as constructors, fields etc etc on how to do that (i.e. shapeless with scala 2, generic meta programming with Scala 3 etc etc etc)

The context of this issue is the PR at tminglei/slick-pg#668 , specifically trying to convert this code block https://github.com/tminglei/slick-pg/blob/dd1ec247049311c5d515e17f634259340ff7ceaa/src/main/scala/com/github/tminglei/slickpg/PgCompositeSupport.scala#L125-L152 to izumi-reflect

[pshirshov]

Well, if you need to extract constructors, you kinda can do it now if you run on JVM by java-reflecting the closest Class[_] which is being preserved by i-r. Of course you have to keep in mind that not every Scala type has an associated constructor so not every LTT holds a Class[_] you can use.

We might support portable constructor reflection: it's indeed possible to generate Functoids within izumi-reflect, that would work perfectly as a safe, fast and portable replacement for Java reflection. That's what I wanted to do for a while, though there is a nasty problem, Functoids in izumi preserve some information (annotations) which is specific to distage and we have no reasonable idea on how to implement a modular/extensible base Functoid macro in i-r instead of duplicating the code straight away.

Regarding the fields/method signatures - all the code is already there, we just need to extend the data model and handle bit more cases in the extractors. We might help you with that if you would like to make a contribution. If you want to be able to call methods reflectively, Functoids may help too, but I would advise against such idea because every new feature slows the compiler down and bloats the binary tag representation.

Also, for your purposes, you might try to use i-r together with other reflection implementations (there are links in our readme).

[neko-kai]

In README we link to other reflection libraries that do this - https://wvlet.org/airframe/docs/airframe-surface & https://github.com/gzoller/scala-reflection (we also extract constructors/methods in izumi) - you may be able to copy these macros/approaches inside slick. Documenting how to use reflection APIs is not trivial, however there are many open source examples on github that may help to understand it.

@mdedetrich ^ the code you linked looks similar to code that extracts constructors in izumi, you may be able to use it as a starting point - https://github.com/7mind/izumi/blob/686da202a7d947c7424d53501ef35472825d5f80/distage/distage-core-api/src/main/scala-3/izumi/distage/constructors/ConstructorUtil.scala#L433

[mdedetrich]

Thanks for the tips, I will wait back for a comment from the projects author

[jdegoes]

@mdedetrich Please open up a feature request to add field names/ constructors and I will ensure it gets prioritized.

[pshirshov]

Actually, a fair share of this is already done in izumi, I've managed to detach most of the Functoid logic from distage. It just needs some cleanup and can be moved into i-r then.