在类型擦除工作 - 推荐的方式？

Question

在 Scala-2.10 之后情况发生了变化，因为现在有dedicated reflection system。 什么是推荐的，最佳实践，社区已经确定的标准方式，以修改类型擦除所造成的缺陷？

情况

我们都知道底层运行时系统（JVM /字节码）缺乏以持久方式完全表示参数化类型的能力。这意味着Scala类型系统可以表达精细的类型关系，这些关系在普通JVM字节代码中缺乏明确的表示。

因此，在创建具体数据实例时，创建的上下文包含有关嵌入数据的精细点的特定知识。只要创建上下文以静态方式连接到使用上下文，即只要两者都在一个编译过程中直接连接，一切都很好，因为我们留在“scala领域”其中任何特定类型的知识都可以在编译器中传递。

但是，只要我们的数据实例（对象实例）通过只保证JVM字节码属性的区域，此链接就会丢失。这可能发生在例如当

• 将数据元素作为消息发送给另一个Actor
• 将其传递给以其他JVM语言编写的子系统（例如OR-Mapper和RDBMS存储）
• 通过JVM序列化和基于顶部的任何编组技术提供数据
• 甚至只是在Scala中，通过任何丢弃特定类型参数信息的函数签名并仅保留某些类型绑定（例如Seq[AnyRef]）或存在类型（Seq[_]）

因此，我们需要一种编组其他特定类型信息的方法。

示例

我们假设我们使用类型Document[Format]。文档通过一系列外部服务API发送和检索，这些API主要以JSON格式进行通信（并且通常不限于仅使用Java的用法）。显然，对于某些特定类型的Format，我们可以编写类型类来掌握如何解析该JSON并将其转换为显式Scala类型的知识。但显然没有希望一个连贯的类型层次结构覆盖任何类型的Document[Format]（除了 格式化文档并且可以转换的事实之外） ）。它表明我们可以优雅地处理所有通用问题（分配负载，处理超时和某些API /服务的可用性，保持持久的数据记录）。但对于任何实际的“业务”功能，我们最终都需要切换到特定类型。

任务

由于JVM字节码无法表示我们需要的类型信息，因此毫无疑问我们需要在Document[Format]中分配一些额外的元数据字段来表示“此文档具有Format XYZ”的信息。因此，通过查看该元数据，我们可以在以后重新获得完全类型化的上下文。

我的问题是关于解决此问题的首选，最充分，最优雅，最强烈的惯用方式。也就是说，当前Scala中的 （＆gt; = Scala-2.10）。

• 如何表示其他类型信息（即上例中的Format）？在文档对象中存储Format.class？或使用类型标签？或者您是否愿意推荐符号表示，例如'Format或"my.package.Format"
• 或者您是否建议存储完整类型信息，例如Document[Format]，建议使用哪种代表？
• 什么是代码中最简洁，最清晰，最清晰，最易读和最易解释的解决方案，以重新建立完整的类型上下文？使用某种模式匹配？使用一些隐含的？使用类型类或视图绑定？

在这种情况下，人们发现什么能够很好地运作？

Answer 1

Scala文档：http://docs.scala-lang.org/overviews/reflection/typetags-manifests.html

来自文章：

  

与scala.reflect.Manifest一样，TypeTags可以被视为对象   其中包含编译时可用的所有类型信息   运行。例如，TypeTag [T]封装了运行时类型   一些编译时类型T的表示。但是请注意   TypeTags应该被认为是更丰富的替代品   清单之前的2.10概念，另外完全集成   用Scala反射。

你也应该看一下清单。