c++ - 这与 ObjectWrap::Unwrap 的 Holder

Question

v8::FunctionCallbackInfo类区分 This 和 Holder。我知道 JavaScript 中的 this 是什么，并假设 This 反射(reflect)了该设置。但是我对 Holder 是什么只有一个模糊的概念，对于什么时候应该使用 Holder 而不是 This 也知之甚少。

特别是，在编写基于 nan 的 node.js 扩展和展开 ObjectWrap 时，我应该传递哪些？

当前 node::ObjectWrap documentation有使用 Holder 的例子，而 current Nan::ObjectWrap documentation使用 This，因此“只需按照文档中的示例”无助于回答这个问题。

Answer 1

在写上面的问题时，我做了更多的挖掘，最终在 v8-users Google Group 上找到了一些相关的话题。 .我将引用这两篇文章中与我最相关的一小部分，但它们是断章取义的，因此包含的主题可能值得阅读以获取更多信息。我添加的格式化标记。

Christian 'Little Jim' Plesner wrote in 2009:

In short: if you specify, through a Signature, that a function must only be called on instances of function template T, the value returned by Holder is guaranteed to hold an instance created from T or another function template that directly or indirectly FunctionTemplate::Inherits from T. No guarantees hold about the type of This.

此语句被Stephan Beal in 2010引用.稍后在同一个线程中，Anton Muhin wrote:

Overall Holder should be always in the prototype chain of This and hence if you read the property, you can freely use both. However setting the property would behave differently if This() != Holder() — the property would end at different object.

这方面又是repeated by Ben Noordhuis in 2014 .

第一个声明似乎表明 Holder 是正确的，应该更改 nan 文档。后者提醒我们，一般来说，This 更合适除非像ObjectWrap 那样直接与某些内部状态交互。

第一个引用的帖子中给出的关于 This 可能是意外类型的示例如下:

var x = { }
x.__proto__ = document;
var div = x.createElement('div');

为此，他写道“出于兼容性原因，我们必须允许这个”。对基于 nan 的扩展类型(来自 nan 测试套件)进行同样的尝试，我发现最近上面的内容似乎导致了 TypeError: Illegal invocation。很明显，签名验证语义发生了一些变化。现在对于 ObjectWrap::Unwrap 来说，无论您使用 This 还是 Holder 似乎都无关紧要。不过，对于 Node 0.10，情况看起来有所不同，所以我认为 Holder 至少对于方法来说应该是首选，并提交了 nan pull request #524关于这个。

访问者的情况要复杂得多。使用 Holder() 不适用于原型(prototype)上安装的访问器，因此显然必须在实例模板上安装访问器，或者使用 This 并执行一些手动类型检查。