这与ObjectWrap :: Unwrap的Holder相比
v8::FunctionCallbackInfo类区分This和Holder 。 我知道this是什么在JavaScript中，并假设This反映了这种设置。 但是我对Holder的含义只有一个模糊的概念，对于什么时候应该使用Holder而不是This ，我的想法很less。
特别是在编写一个基于nan的node.js扩展和ObjectWrap一个ObjectWrap ，我应该传递哪一个？
目前node::ObjectWrap文档有使用Holder例子，而目前的Nan::ObjectWrap文档使用This ，所以“只要按照文档中的例子”就Nan::ObjectWrap这个问题。
在写上面的问题的时候，我做了一些更深入的挖掘，最终在v8用户的Google Group上find了一些相关的线索。 我会引用这两个post的一小部分，这两个post似乎与我最相关，但是它们被取消了，所以包含的线程可能值得阅读以获取更多信息。 格式化标记由我添加。
基督教“小吉姆”Plesner在2009年写道：
简而言之：如果通过
Signature指定一个函数只能在函数模板T实例上被调用，那么Holder返回的值将被保存为由T或者直接或间接的另一个函数模板创build的实例FunctionTemplate::InheritT没有保证持有关于这种types。
这个陈述在2010年被Stephan Beal引用。 后来在同一篇文章中 ， Anton Muhin写道：
整体
Holder应始终在这个原型链，因此，如果你阅读财产，你可以自由使用两者。 但是，如果设置该属性的行为会不同，如果This() != Holder()– 属性将在不同的对象结束。
Ben Noordhuis在2014年再次重申了这一点。
第一个陈述似乎表明Holder是正确的，nan文档应该改变。 后者提醒我们，一般来说， 除非像ObjectWrap那样直接与一些内部状态进行交互， 否则 This更为合适。
在引用的第一篇文章中给出的关于如何This可能是一个意想不到的types的例子如下：
var x = { } x.__proto__ = document; var div = x.createElement('div');
为此他写道：“出于兼容性的原因，我们必须允许这个”。 尝试使用基于南的扩展types（从南方testing套件）相同，我发现这些天，上述似乎导致TypeError: Illegal invocation 。 所以显然签名validation语义有所改变。 对于ObjectWrap::Unwrap这些天来说，无论您使用This还是Holder似乎并不重要。 但是对于节点0.10来说情况看起来不同，所以我认为Holder应该至less用于方法，并且对这个方法提出请求＃524 。
访问者的情况要复杂得多。 使用Holder()将无法在原型上安装访问器，因此显然必须在实例模板上安装访问器，或使用This并执行一些手动types检查。