4 ms·
Sorry I've never used Scala macros, beginner's question: are Scala macros not completely compile time? Why would they use reflection? Is it just syntactic sugar
by nothrabannosir 10y ago
Sorry I've never used Scala macros, beginner's question: are Scala macros not completely compile time? Why would they use reflection? Is it just syntactic sugar for dynamic type inference?
If they just use reflection during compilation: why would that not be compatible with whatever the runtime is? Shouldn't that be unaffected by runtime and purely depend on the compiler's support for reflect?
Or am I looking at this the wrong way?
- airless_bar 10y agoScala macros are compile-time. The Scala reflection library (that works at runtime) share most API with macros. Macros should always work, reflection is harder as some information needs to be retained at runtime (either via Java reflection or additional data – which can both be problematic in Scala.js).
- acjohnson55 10y agoAnd as the original author of Scala.js pointed out in a Scala Days talk today, unrestricted reflection means that it's impossible to do dead code elimination, which is a non-starter for real-world use.
- jfoutz 10y agoI've got at least 30 enterprise applications that disagree with your "nonstarter" assertion. Dead code can only exist in real world code.
- acjohnson55 10y agoI'm talking about within the main use case, which is front-end web development. I guess some folks might be cool with 10MB+ JS apps, but I don't think that would be terribly popular, and certainly not popular enough to bother with imitating Java reflection in JavaScript.
- deleted 10y ago[deleted]
- paulddraper 10y agoWell, Proguard does whole program optimization. You have to specify the symbols to preserve explicitly.
- grogs 10y agoI believe that works against jvm bytecode, which you don't get for scalajs. Instead the compiler has a JS specific intermediate representation which the optimizations occur on.
- Negative1 10y agoPlay uses it specifically for in it’s JSON module; you can define readers and writers that allow you to parse the structure of a JSON object. To avoid having to be very explicit, you can define a case class that directly mirrors the structure of that object. e.g. given some case class that looks like this: case class SomeObj(someInt: Int) you could do: val theObj = SomeObj((json \ “someInt”).as[Int]) or implicit val reads: Reads[SomeObj] = ((json \ “someInt”).read[Int])(SomeObj.apply _) with reflection, you get: implicit reads: Reads[SomeObj] val theObj = reads.validate(json) Seems trivial with this small example but with large objects it keeps your code much more maintainable and consistent since reading and writing from that case class is the same. As far as it not working in Scala.js, from my understanding it has to do with how the reflection library is shared between both runtime and compile time implementations. You can read more about it here: http://docs.scala-lang.org/overviews/reflection/overview.html http://docs.scala-lang.org/overviews/reflection/overview.htm...
- bad_user 10y agoThe tricks that Play JSON does don't need runtime reflection. Macros don't use runtime capabilities at all and all macros work in Scala.js. I'm actually surprised by claims of Play JSON needing the runtime reflection of "scala.reflect". No, Play JSON doesn't work because it wraps Jackson, a Java library.
- grogs 10y agoYour correct that it probably doesn't use scala.reflect, but it still uses reflection. Jackson works using reflection. Play JSON therefore at least depends on reflection transatively.