final

final 属性是 structural 属性的反面。它配置了 wasm-bindgen 如何生成 JS 导入以调用导入的函数。值得注意的是，通过 final 导入的函数在导入后永远不会改变，而通过默认（或使用 structural）导入的函数会受到运行时查找规则的影响，例如遍历对象的原型链。请注意，final 不适合访问 JS 对象的数据描述符属性；要实现这一点，请使用 structural 属性。

final 属性旨在纯粹与性能相关。理想情况下，它对用户没有可见的影响，并且 structural 导入（默认）应该能够最终透明地切换到 final。

最终的性能方面是，使用组件模型提案，wasm-bindgen 将需要生成的 JS 函数垫片比现在少得多。例如，考虑今天这个导入


# #![allow(unused_variables)]
#fn main() {
#[wasm_bindgen]
extern "C" {
    type Foo;
    #[wasm_bindgen(method)]
    fn bar(this: &Foo, argument: &str) -> JsValue;
}
#}

没有 final 属性 生成的 JS 看起来像这样

// without `final`
export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
    let varg1 = getStringFromWasm(arg1, arg2);
    return addHeapObject(getObject(arg0).bar(varg1));
}

我们可以看到这里需要这个 JS 函数垫片，但它都相对独立。但是，它确实以鸭子类型的方式执行 bar 方法，因为它从不验证 getObject(arg0) 是否为 Foo 类型来实际调用 Foo.prototype.bar 方法。

如果我们改为这样写


# #![allow(unused_variables)]
#fn main() {
#[wasm_bindgen]
extern "C" {
    type Foo;
    #[wasm_bindgen(method, final)] // note the change here
    fn bar(this: &Foo, argument: &str) -> JsValue;
}
#}

它会生成这个 JS 胶水（大致）

const __wbg_bar_target = Foo.prototype.bar;

export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
    let varg1 = getStringFromWasm(arg1, arg2);
    return addHeapObject(__wbg_bar_target.call(getObject(arg0), varg1));
}

这里的区别很微妙，但我们可以看到被调用的函数是如何从生成的垫片中提升出来，并始终绑定到 Foo.prototype.bar。然后它使用 Function.call 方法来调用该函数，并将 getObject(arg0) 作为接收者。

但是等等，即使使用 final，这里仍然有一个 JS 函数垫片！这是真的，这仅仅是未来 WebAssembly 提案尚未实施的事实。但是，语义与未来的组件模型提案相匹配，因为被调用的方法只确定一次，并且它位于原型链上，而不是在函数被调用时在运行时解析。

如果您想了解我们的 JS 函数垫片将如何完全消除，让我们看一下生成的绑定。我们从这个开始

const __wbg_bar_target = Foo.prototype.bar;

export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
    let varg1 = getStringFromWasm(arg1, arg2);
    return addHeapObject(__wbg_bar_target.call(getObject(arg0), varg1));
}

... 并且一旦引用类型提案被实施，我们就不需要一些烦人的函数。这将改变我们生成的 JS 垫片，使其看起来像

const __wbg_bar_target = Foo.prototype.bar;

export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
    let varg1 = getStringFromWasm(arg1, arg2);
    return __wbg_bar_target.call(arg0, varg1);
}

越来越好了！接下来我们需要组件模型提案。请注意，该提案目前正在进行一些更改，因此很难链接到参考文档，但足以说明它将至少为我们提供两种不同的功能。

首先，组件模型承诺提供“参数转换”的概念。这里的 arg1 和 arg2 值实际上是指针和长度，指向一个 utf-8 编码的字符串，使用组件模型，我们将能够注释这个导入应该接受这两个参数并将它们转换为 JS 字符串（也就是说，主机应该这样做，WebAssembly 引擎）。使用该功能，我们可以进一步将其缩减为

const __wbg_bar_target = Foo.prototype.bar;

export function __wbg_bar_a81456386e6b526f(arg0, varg1) {
    return __wbg_bar_target.call(arg0, varg1);
}

最后，组件模型提案的第二个承诺是，我们可以标记一个函数调用，以指示第一个参数是函数调用的 this 绑定。今天，所有被调用导入函数的 this 值都是 undefined，而这个标志（使用组件模型配置）将指示这里第一个参数实际上是 this。

考虑到这一点，我们可以进一步将其转换为

export const __wbg_bar_a81456386e6b526f = Foo.prototype.bar;

瞧！我们使用引用类型和组件模型，现在根本不需要任何 JS 函数垫片来调用导入的函数。此外，未来对 ES 模块系统的 wasm 提案也可能意味着我们甚至不需要这里的 export const ...。

还值得指出的是，在所有这些 wasm 提案实施后，导入 bar 函数的默认方式（即 structural）将生成一个看起来像这样的 JS 函数垫片

export function __wbg_bar_a81456386e6b526f(varg1) {
    return this.bar(varg1);
}

其中这个导入仍然受制于运行时原型链查找等。

`wasm-bindgen` 指南

与未来提案的交互

`final`