#IDL for ECMAScript S1

中文标题：ECMAScript 的接口描述语言

#ECMAScript 的接口描述语言

阶段 1

本仓库旨在调查在 ECMAScript 标准中使用接口描述语言（IDL）的可能性。目前它尚未达到 TC39 的任何阶段。

感谢 Yehuda Katz、Alex Russell、Brian Terlson、Domenic Denicola、Tobie Langel、Anne van Kesteren、Cameron McCormack 等人在这一领域的巨大努力，使这项调查成为可能。

#动机

#当前方法的问题

TC39 一直在使用规范中 算法约定 部分定义的“ecmaspeak”表示法逐步增加其标准库。这提供了两个主要组成部分：

• 方法通过标题声明，标题指出它们是哪个对象的属性、接受哪些参数（仅作为名称），并暗示函数对象的 "length" 属性。
• 参数和接收者通过显式的 ToObject、ToString、ToLength、RequireObjectCoercible 等调用进行强制转换；选项包通过 Get 访问；一般来说，处理和理解参数的所有内容都散布在通用算法的定义中。

#在新规范中遵循约定的容易性

参数处理的自由形式使得可靠地遵循约定变得困难。例如，在 Intl 中，我们遇到了一些问题，其中不清楚处理选项包、使构造函数和原型链工作等的适当方式是什么。Ecmaspeak 在这方面提供了许多自由度，并且约定没有在任何地方正式记录。记录约定可以让我们部分实现目标，但如果我们有一种语言可以简洁地描述接口的“绑定”部分，那么更容易坚持这些约定。

#在原生实现中自动生成绑定

JavaScript 实现需要为 ECMAScript 规范定义的内置对象和方法创建对象图。目前，这通常通过显式声明所有对象和方法的 JavaScript 或 C++ 代码，并以命令式方式构造它们来完成。

相比之下，在 Web 浏览器中，Web 平台 API 通常通过其 WebIDL 描述，并且可以直接生成到 C++ 实现的绑定。这种基于 IDL 的方法有许多优点：

• 更容易维护设置对象图的代码，并确保其与规范匹配
• 规范作者和实现者可以在某种程度上抽象于 JavaScript 细节的方面进行改进
• 规范更改可以通过复制粘贴传播到实现中（除了特定于浏览器的 WebIDL 功能——正在进行的工作旨在尽量减少对这些功能的需求）

#工具的“类型”定义

许多工具需要处理 JavaScript 的标准库，例如：

• IDE 中的代码补全
• 像 TypeScript 和 Flow 这样的类型系统
• JavaScript 与其他编程语言之间的绑定，如 wasm-bindgen

这些工具通常可以使用 WebIDL 作为 Web 规范的“类型定义”。然而，对于 JavaScript 标准库，需要额外的资源。我们最终得到 N×M 的工作量，为每个工具、每个库特性重复定义。

#要求

以下是关于 JavaScript IDL 要求的一些初步说明；这些初步想法需要在阶段 1 调查过程中更详细地阐述。这里的重点是针对 WebIDL 的差异。

#参数的类型转换

在 ECMAScript 方法中，参数和接收者通常被转换为或检查为特定的“类型”，例如，使用 ToUint32 等操作。这些可以概念上成为 IDL 中“类型声明”的一部分。

#惰性

有时，参数是“惰性”转换的，在算法中间而不是预先进行。这里的想法是匹配 JavaScript 程序员实现算法的方式。这种惰性不同于 WebIDL，后者在进入方法时进行所有转换和检查。

#重载

JavaScript 构造函数通常在参数类型上进行重载。这里的重载模式可能匹配也可能不匹配 WebIDL 对混合参数的约束。

#匹配 JS 约定

这里有很多小事需要处理，例如，JavaScript 内置方法是不可枚举的，而在 WebIDL 中它们是可枚举的。

#直观的语法

WebIDL 语法对 JavaScript 开发人员来说可能看起来陌生。我们可能需要确保 ECMAScript 中使用的 IDL 具有足够直观的语法。

#使用哪种语言？

#WebIDL

WebIDL 是 Web 规范用来声明接口和类型转换的语言。在 ECMAScript 中使用 WebIDL 的一些优点包括：

• 规范可以以更统一的方式开发，无论地点如何，从而实现更多的共享和交叉融合
• WebIDL 的某些基础设施可能可以“免费”用于 JavaScript
• WebIDL 的附加功能以支持 JavaScript 可能对 WebIDL 的其他用途有用；对标准基础设施的改进可能带来广泛的益处
• 从最小化复杂性的角度来看，如果宇宙中只有一个 IDL 而不是两个，会更简单
• 当非 Web、非 Ecma 系统需要 IDL（例如 Node.js，或嵌入具有自定义 C++ 绑定的 Web 引擎的系统）时，WebIDL 成为通用选择会更明确

在 ECMAScript 中使用 WebIDL 的想法已被 WebIDL 当前的维护者积极接纳。有关支持 JavaScript 的问题，请参见跟踪标签。

#JSIDL

之前的努力 解决这个问题涉及提出一个新的 ECMAScript IDL。走上这条道路的一些原因：

• JavaScript 所需的功能集与 Web 不同。它们遵循不同的约定，例如可枚举性、重载、转换类型等。重叠只是部分的。
• 实际上，处理 JSIDL 的某些软件将不同于使用 WebIDL 的软件（例如，某些 JS 引擎可能无法重用用于 Web API 的 WebIDL 生成器，需要单独的生成器）
• 从最小化复杂性的角度，JSIDL 将是比整个 WebIDL 更小的定义。

#让我们推迟决定

TC39 成员中有 WebIDL 和 JSIDL 两条路径的坚定支持者。本提案仓库的意图是首先收集需求并起草我们希望 ECMAScript 规范的样子，然后根据调查结果，确定我们是否要追求使用带扩展的 WebIDL，还是使用单独的 JSIDL。

#从这里开始的计划

就 TC39 阶段流程而言，计划了以下里程碑，与进入每个阶段相关：

1. 进入阶段 1：我们同意讨论该主题
   • 阶段 1 期间：讨论要求，研究技术备选方案——当前点
2. 进入阶段 2：就 WebIDL 与 JSIDL 达成一致；IDL 本身的初稿；为 JS 的至少一个主要组件起草 IDL 转换
   • 阶段 2 期间：将更多 JS 规范正式化为 IDL，并正式化 IDL 定义本身；在工具中试验 IDL 的自动使用
3. 进入阶段 3：整个规范转换为 IDL，IDL 定义完全严格；至少有一个工具使用该 IDL
   • 阶段 3 期间：在工具、测试和原生实现中进一步使用 IDL
4. 进入阶段 4：至少一个原生实现使用从 IDL 生成的代码；至少两个原生实现实现任何/所有规范更改；test262 使用 IDL 穷举测试类型转换；准备对整个规范的 PR