這與ObjectWrap :: Unwrap的Holder相比

Question

v8::FunctionCallbackInfo類區分This和Holder 。 我知道this在JavaScript中是什么，並假設This反映了該設置。 但我對Holder概念只有一個含糊不清的概念，而且我何時應該使用Holder而不是This 。

特別是，當編寫基於nan的node.js擴展並展開ObjectWrap ，我應該通過哪些？

目前node::ObjectWrap文檔中有使用Holder示例，而當前的Nan::ObjectWrap文檔使用This ，所以“只需按照文檔中的示例”就Nan::ObjectWrap這個問題。

Answer 1

在寫上面的問題時，我做了一些挖掘，並最終在v8用戶Google Group上找到了一些相關主題。 我將引用這兩個與我最相關的帖子中的一小部分，但它們是脫離了上下文的，所以包含的內容可能值得閱讀以獲取更多信息。 格式化標記由我添加。

Christian'Little Jim'Plesner在2009年寫道：

簡而言之：如果通過Signature指定只能在函數模板T實例上調用函數，則Holder返回的值保證保存從T或其他函數模板創建的實例，該函數直接或間接地為FunctionTemplate::Inherit自T 無擔保容納約的類型This 。

此聲明由Stephan Beal在2010年引用。 后來在同一個主題中， Anton Muhin寫道：

總體Holder應始終處於原型鏈This ，因此如果你讀的屬性，您可以自由使用這兩種。 但是，如果This() != Holder() - 屬性將以不同的對象結束，則設置屬性的行為會有所不同。

Ben Noordhuis在2014年再次重申了這一方面。

第一個聲明似乎表明Holder是正確的，應該更改nan文檔。 后者提醒我們，一般來說， 除非有人像ObjectWrap那樣直接與某個內部狀態進行交互， 否則 This更合適。

第一篇引用文章中給出的關於This可能是一種意外類型的例子如下：

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

為此，他寫道“出於兼容性原因，我們必須允許這個”。 嘗試使用基於nan的擴展類型（來自nan測試套件），我發現這些天以上似乎導致了TypeError: Illegal invocation 。 顯然，簽名驗證語義已經有所改變。 對於ObjectWrap::Unwrap無論你使用This還是Holder This似乎都不重要。 然而，對於節點0.10來說情況看起來不同，所以我認為Holder應該首選至少用於方法，並提交關於此的nan pull request＃524 。

訪問者的情況要復雜得多。 使用Holder()不適用於原型上安裝的訪問器，因此顯然要么必須在實例模板上安裝訪問器，要么使用This並進行一些手動類型檢查。