为什么 Scala API 有两种组织类型的策略？

Question

我注意到 Scala 标准库使用两种不同的策略来组织类、特征和单例对象。

1. 使用其成员已导入的包。例如，这就是访问 scala.collection.mutable.ListBuffer 的方式。这种技术在 Java、Python 等中很常见。

2. 使用特征的类型成员。例如，这就是您访问 Parser 类型的方式。您首先需要混合scala.util.parsing.combinator.Parsers。这种技术在 Java、Python 等中并不常见，并且在第三方库中使用不多。

我猜 (2) 的优点之一是它组织了方法和类型，但根据 Scala 2.8 的包对象，使用 (1) 也可以完成同样的事情。为什么要采用这两种策略？每种应该什么时候使用？

Answer 1

这里值得注意的命名法是路径相关类型。这就是你所说的选项 2，我只谈它。除非您碰巧用它解决了问题，否则您应该始终采用选项 1。

您错过的是 Parser 类引用 Parsers 类中定义的内容。事实上，Parser 类本身取决于 Parsers 上定义的 input：

abstract class Parser[+T] extends (Input => ParseResult[T])

定义了 Input 类型像这样：

type Input = Reader[Elem]

Elem 是抽象的。例如，考虑一下 RegexParsers 和 TokenParsers。前者将Elem定义为Char，后者将其定义为Token。这意味着每个的 Parser 是不同的。更重要的是，由于 Parser 是 Parsers 的子类，Scala 编译器将确保在编译时您不会传递 RegexParsers 的Parser 到 TokenParsers 或反之亦然。事实上，您甚至无法将 RegexParsers 的一个实例的 Parser 传递给它的另一个实例。

Answer 2

第二个也称为蛋糕模式。
它的好处是，混合有特征的类内的代码变得独立于该特征中方法和类型的特定实现。它允许使用特征的成员而不知道它们的具体实现是什么。

trait Logging {
  def log(msg: String)
}

trait App extends Logging {
  log("My app started.")
}

上面，Logging 特征是对 App 的需求（需求也可以用自我类型来表达）。然后，在应用程序中的某个时刻，您可以决定实现是什么，并将实现特征混合到具体的类中。

trait ConsoleLogging extends Logging {
  def log(msg: String) = println(msg)
}

object MyApp extends App with ConsoleLogging

与导入相比，这具有优势，因为您的代码段的要求不受 import 语句定义的实现的约束。此外，它允许您构建和分发一个 API，该 API 可以在其他地方的不同构建中使用，前提是通过混合具体实现来满足其要求。

但是，使用此模式时需要注意一些事项。

1. 特征内定义的所有类都将引用外部类。这可能是一个涉及性能的问题，或者当您使用序列化时（当外部类不可序列化时，或更糟糕的是，如果可以序列化，但您不希望它被序列化）。
2. 如果您的“模块”变得非常大，您将要么拥有非常大的特征和非常大的源文件，要么必须将模块特征代码分布在多个文件中。这可能会导致一些样板文件。
3. 它可能迫使您必须使用此范例来编写整个应用程序。在您知道之前，每个类都必须混合其要求。
4. 具体实现必须在编译时知道，除非您使用某种手写委托。您不能根据运行时可用的值动态地混合实现特征。

我猜库设计者并没有将上述任何问题视为解析器所关心的问题。