相互递归类型的阶(mutually recursive types in scala)

是否有可能有共同的递归类型Scala呢？

我有一个的错误追踪系统问题列表的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, ...)

我不知道这是否相互递归在理论上是可能的吗？

第二个问题：

我渲染模型的一些维基的标记。这工作得很好用重载递归渲染（）：字符串在类的数据类型。（或许我应该有一个“渲染”超类！？）

什么是用于分析最彻底的方法，也就是我想有一个递归

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

我会放在哪里呢？它会是什么样子？ IIUC，同伴是自动生成的情况下类，所以我不能给它添加？

我有这样的例如：

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

但是，我没有给功能的类型。什么是该函数的类型？

我也想过直接传递XML：马到ADT的构造函数，那会是聪明？或者我应该分开XML的解析和模型的创造？

耶稣，学习斯卡拉基本知识，并做一些脚本和函数（想太多JAVA）之后，我终于明白了如何写抽象数据类型，可以表达自己几乎一样的好老哈斯克尔次:-)

答：关于一成不变的，相互依存类的初始化，看看这个问题。

B：关于你的问题render: Foo => String功能与Renderable超类，这是IMHO或多或少的功能和面向对象的方法之间的设计决策。我个人不认为他们中的一个是优于其他，它只是一个品味的问题。论文“独立扩展的解决方案，以表达问题”有两个之间的一个很好的对比，尽管在一个稍微更复杂的情况下（这是一个伟大的阅读，不过）。

C：伴侣对象由编译器创建的，但如果还指定了一个同伴对象，编译器将合并这两个。

d：在当前的类层次结构不存在用于非平凡普通超Issue和Field ，这使得它很难给出一个有意义的返回类型fromXML 。你可以与合作Either[Issue, Field] ，虽然，但这个看起来腥给我。在一般情况下，我会避免混合，都应该返回全面节点（例如，职能Task与那些返回“内部”的节点（例如，） Status ）。

E：做了你看看现有的解决方案，如scalaxb ？你可以找到更多的链接在这里和这里。