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

Question

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

使用其成员为导入的包。例如，这就是您访问 scala.collection.mutable.ListBuffer 的方式。 .这种技术很熟悉来自 Java、Python 等。

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

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

Answer 1

此处注意的命名法是 path-dependent types .这就是你所说的选项 2，我只说它。除非你碰巧有一个问题被它解决了，否则你应该总是选择选项 1。

你错过的是Parser类引用了 Parsers 中定义的东西类(class)。事实上，Parser类本身取决于什么input已在 Parsers 上定义:

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或相反亦然。事实上，你甚至过不了 Parser RegexParsers 的一个实例到它的另一个实例。