scala - 解释 - 不涉及反射

Question

我有一个非常简单的问题。这不仅适用于 spray-json，而且我已经阅读了 argonaut 和 circe 的类似声明。所以请赐教。
在 spray-json 中，我遇到了 There is no reflection involved 的声明。 .我理解基于类型类的方法，如果用户提供 JsonFormat 那么一切都很好。但是，在使用 DefaultJsonProtocol 时，这种说法是否也成立？ ?
因为当我们看 this ，可以看到clazz.getMethods的用法, clazz.getDeclaredFields等等。这不就是反射的用法吗？当然感谢 object#apply与使用反射的 Java 世界不同，我们无需担心设置。但至少对于阅读字段名称，我不明白如何忽略反射。

Answer 1

我对 spray-json 不是很熟悉，所以我不会为它关于反射的说法辩护，这似乎与 ProductFormats 的部分内容不一致。你指向。

我确实更了解 circe 和 Argonaut 以及 argonaut-shapeless 和 Play JSON，所有这些都使用一种反射来为案例类和其他用户定义的类型派生编解码器。重要的一点是这些库不使用运行时反射——它们通过 Scala 的宏系统在编译时确定它们需要的字段名称和其他信息。

通常人们在 Java 或 Scala 的上下文中谈论“反射”时，他们的意思是运行时反射，但宏也支持一种反射，所以当我个人谈论这些库中的派生如何工作时，我会尽量小心地指定不涉及运行时反射。

您可以争辩说编译时反射(或元编程，或任何您想称呼它的东西)比运行时反射要好得多。它可能会使您的代码更复杂，并且很容易被滥用，但它不会引入与运行时反射相同的脆弱性，并且不会破坏您以与运行时反射相同的方式推理代码的能力做。如果您了解宏的作用(这是一个很大的 if)，那么您在运行时永远不会感到惊讶。

类型本质上是在你运行它们之前拒绝潜在的不良程序，并且在运行时对类型的自省(introspection)会混淆这一切(如 Erik Osheim says ，“如果你在运行时遇到一个类型，就杀死它”)。另一方面，编译时对类型的自省(introspection)正是编译器所做的，而宏只是为程序员提供了一种参与该过程的干净方式(或者至少相对干净，与编写编译器插件等相比)。 )。

避免运行时反射也可能带来性能上的好处，但对我个人而言，这通常是次要问题——我讨厌运行时反射，因为我浪费了太多时间来调试糟糕的 Java 代码，这些代码使用严重依赖运行时反射的糟糕的 Java 库——不是因为运行时反射可能会使我的程序稍微变慢。

这是一种非常冗长的说法，在这种情况下您应该将“不涉及反射”阅读为“不涉及运行时反射”(即使那样，您也不应该相信作者的话，我猜，考虑到所有 getMethods 的东西在 spray-json 中)。