Skip to content

Meta-programming: runtime reflection support? #5639

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
liufengyun opened this issue Dec 17, 2018 · 4 comments
Closed

Meta-programming: runtime reflection support? #5639

liufengyun opened this issue Dec 17, 2018 · 4 comments

Comments

@liufengyun
Copy link
Contributor

ScalaTest depends on runtime reflection in several places:

The question is: should tasty reflection provide similar support at run-time? What is the story for cross-platform support?

@ritschwumm
Copy link

at least at first glance ObjectMeta looks like it what it does could (and maybe even should) be done at compiletime. Framework.scala like it could easily be implemented with plain java runtime reflection.

@liufengyun
Copy link
Contributor Author

liufengyun commented Dec 18, 2018

Indeed, actually in Framework.scala, the implementation is based on Java reflection for Scala 2.10. I don't understand why it uses scala-reflect for > 2.10.

Regarding ObjectMeta, more generally, can we conjecture that run-time reflection can always be implemented by compile-time reflection ? It seems possible to me, only the meta-information has to be materialized at compile-time when the value is created and propagate along with the value to where the meta-information is required. However, to which extent it affects usability is another issue, at least in ScalaTest, big refactoring is required.

@liufengyun
Copy link
Contributor Author

Close now, run-time reflection is out of scope, given the portability problem it causes. We will evaluate the impact on the ScalaTest project.

@gzoller
Copy link
Contributor

gzoller commented Sep 12, 2019

Bump -- Please consider impact on ScalaJack project too! We use runtime reflection/TypeTag everywhere to provide frictionless JSON serialization. One, among many, typical uses is the "Pet problem":

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

ScalaJack uses runtime reflection to examine the List[Pet] to find the actual, concrete type of each Pet, render the type hint, and obtain (recursively) all the constructor fields. It gets far more involved when you include collections, and type parameters, but this gives you a flavor.

It's very possible I don't yet understand Dotty's meta programming--I'm struggling to grok it--but thus far I haven't seen/understood a mechanism that would solve this problem.

(Wouldn't most JSON serializers for Scala do something similar?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants