scala中的相互递归类型

Question

scala 中是否可以有相互递归的类型？

我有一个包含 bugtracker 问题列表的 xml 文件。是原始数据。该模型具有不同的问题类型，例如“任务”、“子任务”、“错误”、“特殊错误”。

现在我想将我的原始数据解析为任务和子任务的层次结构：

// data type for field contents
abstract class Field
case class Id(raw : string) extends Field
case class Status(raw : string) extends Field
...

// data type for primary model
abstract class Issue(id : String, ...)
case class Task(id : Id, status : Status ..., subtasks : List[Subtask] ) extends Issue(id, ...)
case class Subtask(id : Id, status : Status ..., parent: Task) extends Issue(id, ...)

不知道这种相互递归在理论上是否可行？

第二个问题：

我将模型渲染为一些 wiki 标记。这适用于重载的递归 render() ：数据类型的类中的字符串。 （也许我应该有一个“可渲染”的超类！？）

什么是最干净的解析方式，即我想要一个递归

fromXML : scala.xml.Elem => Issue / Field

我会把它放在哪里？它会是什么样子？ IIUC，同伴是为案例类自动生成的，所以我不能添加它？

我有这个例如：

def fromXml(e : Elem) = e match {
  case <a>test</a> => Id("test") 
  case _ => Status("Pre-analysed")
}

但是我没有给函数一个类型。 是那个函数的类型？

我也想过将xml-elem直接传递给ADT的构造函数，这样会不会很聪明？还是应该将 XML 解析和模型创建分开？

---

天哪，在学习了 scala 基础知识并编写了一些脚本和函数（并且想太多 java）之后，我终于明白了如何编写 ADT，并且可以像在过去的 Haskell 时代一样表达自己:-)

Answer 1

答：关于不可变、相互依赖的类的初始化，请看this question。

B：关于您的问题render: Foo => String 函数与Renderable 超类，恕我直言，这或多或少是函数式方法和面向对象方法之间的设计决定。我个人并不认为其中一个优于另一个，这只是品味问题。论文"Independently Extensible Solutions to the Expression Problem" 对两者进行了很好的比较，尽管在稍微复杂的背景下（不过，这是一本很好的读物）。

C: Companion 对象由编译器创建，但如果您还指定了一个 Companion 对象，编译器会将两者合并。

D：在您当前的类层次结构中，Issue 和 Field 没有重要的公共超类型，这使得为 fromXML 提供有意义的返回类型变得困难。不过，您可以使用Either[Issue, Field]，但这对我来说看起来很可疑。一般来说，我会避免将应该返回成熟节点（例如，Task）的函数与返回“内部”节点（例如，Status）的函数混合使用。

E：您是否看过现有的解决方案，例如scalaxb?您可以找到更多链接here 和here。