lampepfl / dotty-feature-requests

Historical feature requests. Please create new feature requests at https://github.com/lampepfl/dotty/discussions/new?category=feature-requests
31 stars 2 forks source link

Reflection Please #68

Open gzoller opened 5 years ago

gzoller commented 5 years ago

I have noticed that reflection hasn't been something the Dotty team has been very excited about so far. Please reconsider, and add reflection to Dotty/Scala3.

A number of projects rely deeply on this feature. I fully admit I don't understand all the new metaprogramming features in Dotty, it doesn't seem to be the same thing as full runtime reflection.

For example my project, ScalaJack, is a JSON serializer. I presume most serializers like mine will rely on TypeTag reflection to do its job. ScalaJack reflects on a LOT of information, especially when trying to understand parameterized types, collections, etc. Getting the concrete classes at runtime that associate with a trait-type is especially important, like this:

trait Pet{ name: String }
case class Cat(name: String, isPurring: Boolean) extends Pet
case class Dog(name: String) extends Pet
case class Pets(all:List[Pet])

val pets = Pets(List(Cat("Slinky",true),Dog("Spot"))
val sj = ScalaJack()
val js = sj.render(p) 
// renders:  {"all":[{"_hint":"com.mypackage.Cat","name":"Slinky","isPurring":true},{"_hint":"com.mypackage.Dog","name":"Spot"}]}
val orig = sj.read[Pets](js)  // builds the original object hierarchy using the hints

What you see here is that ScalaJack figures out each concrete Pet implementation is in the list and handles appropriately (generates the type _hint, gets the case class constructor members, etc.) So far I haven't seen/understood how this could be done with Dotty's current metaprogramming model at compile-time.

For parameterized types ScalaJack dives deep into the TypeTag to match all the symbols to their runtime types, e.g. Foo[T] where T is a Bar[T,U] where T & U are scalars (complex nesting of parameterized types, essentially, where those types may also be traits that must be unpacked at runtime according to their concrete implementations).

If this is possible at compile-time we need a whole lot more documentation/examples, but for now I'm thinking this needs true runtime reflection.

It doesn't have to be perfect or pure (cover every nuanced detail)--we just need some way to get at basic visibility into these runtime objects.

pshirshov commented 5 years ago

Duplicate of https://github.com/lampepfl/dotty-feature-requests/issues/62 Also here is the discussion: https://contributors.scala-lang.org/t/scala-3-and-reflection/3627