为什么 Type 脚本使用关键字“ export”使类和接口公开?

在涉足 Typecript 时,我意识到我的模块中的类(用作名称空间)不能用于其他类,除非我在它们之前编写了 export关键字,例如:

module some.namespace.here
{
export class SomeClass{..}
}

现在我可以像这样使用上面的代码:

var someVar = new some.namespace.here.SomeClass();

然而,我只是想知道为什么使用这个关键字,而不是仅仅使用 public关键字,这个关键字在方法级别用来表示方法或属性应该是可以从外部访问的。那么,为什么不使用同样的机制使类和接口等外部可见呢?

这将产生如下代码:

module some.namespace.here
{
public class SomeClass{..}
}
86004 次浏览

主要原因是 export与 ECMAScript 的计划相匹配。你可能会说“他们应该使用“ export”而不是“ public”,但是除了“ export/private/protected”是一组不匹配的访问修饰符之外,我相信这两者之间有一个微妙的区别来解释这一点。

在 TypeScript 中,将类成员标记为 publicprivate对生成的 JavaScript 没有影响。它只是一个设计/编译时工具,您可以使用它来阻止 TypeScript 代码访问它不应该访问的内容。

通过使用 export关键字,JavaScript 添加一行来将导出的项添加到模块中。在你的例子中: here.SomeClass = SomeClass;

因此,从概念上讲,由 publicprivate控制的可见性仅用于工具,而 export关键字改变输出。

对于史蒂夫•芬顿(Steve Fenton)的回答,有几点需要补充:

  • export 已经意味着两个不同的东西(取决于它是否在顶级) ; 使它意味着三分之一可能比增加 public/private更糟糕
  • 这肯定不是为了使实现更容易; publicexport之间增加的复杂性是微不足道的。我们已经改变了很多关键词,这并不困难。
  • 类成员 必须的的默认可见性为 public,以便与 ES6类建议保持一致,因此我们需要一些关键字来表示“非 public”。export(unexport? ?)没有合适的反义词因此 private是合乎逻辑的选择。一旦你有 private,这将是有点疯狂,不选择 public作为其对应物
  • 使用 export修改内部模块中的可见性是与 ES6模块的最佳匹配