的解释-不涉及反思 [英] Explanation for - No Reflection involved
问题描述
我有一个非常简单的问题.这不仅适用于spray-json，而且我已经阅读了有关argonaut和circe的类似声明.所以请赐教.
I have a very simple question. This is not only true with spray-json but I have read similar claims with argonaut and circe. So please enlighten me.
在spray-json中，我遇到了说There is no reflection involved的语句.我了解基于类型类的方法，如果用户提供JsonFormat，那么一切都很好.但是在使用DefaultJsonProtocol时，这种说法是否也正确?
In spray-json, I have come across the statement saying There is no reflection involved. I understand for type class based approach, if the user provides JsonFormat then all is well. But is this claim also true when it comes to using DefaultJsonProtocol?
Because when we you look at this, you can see the usage of clazz.getMethods, clazz.getDeclaredFields etc. Isn't this the usage of reflection? Though of-course thanks to object#apply that we do not need to worry about setting unlike in Java world using reflection. But atleast for reading the field names, I do not understand on how reflection can be over-looked.
推荐答案
我对spray-json不太熟悉，因此我不会捍卫其关于反射的主张，这肯定与ProductFormats您指向.
I'm not very familiar with spray-json, so I won't defend its claims about reflection, which definitely seem to be at odds with the parts of ProductFormats you point to.
我确实了解更多关于circe和Argonaut以及argonaut-shapeless和Play JSON的信息，所有这些都使用一种反射来导出案例类和其他用户定义类型的编解码器.重要的一点是，这些库不使用 runtime 反射-它们通过Scala的宏系统来确定它们在编译时所需的字段名称和其他信息.
I do know more about circe and Argonaut and argonaut-shapeless and Play JSON, all of which do use a kind of reflection to derive codecs for case classes and other user-defined types. The important point is that these libraries don't use runtime reflection—they determine the field names and other information they need at compile time through Scala's macro system.
通常，当人们在Java或Scala上下文中谈论反射"时，它们的意思是运行时反射，但是宏也支持某种反射，因此当我亲自谈论派生在这些库中的工作方式时，我会尝试请谨慎指定不涉及任何运行时反射.
Generally when people talk about "reflection" in the context of Java or Scala, they mean runtime reflection, but macros also support a kind of reflection, so when I personally talk about how derivation works in these libraries, I try to be careful to specify that there's no runtime reflection involved.
您可以辩称，编译时反射(或元编程，或您想调用的任何东西)比运行时反射的危害要小得多.它可能会使您的代码更加复杂，并且很容易被滥用，但是它不会引入与运行时反射相同的脆弱性，并且不会损害您以与运行时反射相同的方式进行代码推理的能力.做.如果您了解宏的功能( if 很大)，那么运行时就不会感到惊讶.
You can argue that compile-time reflection (or metaprogramming, or whatever you want to call it) is much less bad than runtime reflection. It may make your code more complex, and it's very easy to abuse, but it doesn't introduce the same kinds of fragility as runtime reflection, and it doesn't undermine your ability to reason about your code in the same ways that runtime reflection does. If you understand what the macro does (which is a big if), you'll never be surprised at runtime.
从根本上讲，类型是关于在运行程序之前拒绝可能存在的不良程序，而在运行时对类型进行自省会混淆所有这些(如 Erik Osheim说，如果您在运行时遇到Type，则将其杀死").另一方面，编译时对类型的自省恰恰是编译器的工作，宏只是为程序员提供了一种介入该过程的干净方法(与编写编译器插件等相比，它至少是相对干净的). ).
Types are fundamentally about rejecting bad potential programs before you run them, and introspection on types at runtime muddles this all up (as Erik Osheim says, "If you meet a Type in the Runtime, kill it"). On the other hand, introspection on types at compile-time is exactly what compilers do, and macros just give you as the programmer a clean way of getting involved in that process (or at least relatively clean, compared to writing compiler plugins, etc.).
避免运行时反射也可能会带来性能上的好处，但是对我个人而言，这通常是个次要问题-我讨厌运行时反射，因为我浪费了很多时间来调试使用严重依赖Java的Java库的可怕Java代码运行时反射-不是因为运行时反射可能使我的程序慢一点.
There may also be performance benefits to avoiding runtime reflection, but for me personally that's generally a secondary concern—I hate runtime reflection because I've wasted too much of my life debugging horrible Java code that uses horrible Java libraries that depend heavily on runtime reflection—not because runtime reflection might make my programs marginally slower.
这是一条漫长的路要说，在这种情况下，您应该阅读不涉及任何反射"，因为不涉及运行时反射"(即使那样，您也不应以作者的话为准) ，考虑到Spray-json中的所有getMethods内容).
That's all a very long-winded way to say that you should read "there is no reflection involved" in this context as "there is no runtime reflection involved" (and even then you shouldn't take the author at their word, I guess, given all that getMethods stuff in spray-json).
这篇关于的解释-不涉及反思的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
