Pass Holder instead of This to ObjectWrap::Unwrap

[gagern]

This is after reading Christian 'Little Jim' Plesner's answer to “What is the difference between Arguments::Holder() and Arguments::This()?” in the context of my Stack Overflow question “This vs. Holder for ObjectWrap::Unwrap”. Without the fix in my second commit, the test case from my first commit can lead to a failed assertion on Node 0.10. The change is also in line with the node::ObjectWrap documentation.

[kkoopa]

I know there is a difference between Holder and This, and I roughly know what said difference is. While using Holder probably is what is intended in most cases, this PR only changes tests, which need not necessarily reflect the best development practices with regard to V8 (although I am aware they are used as examples and references and should probably maintain some quality).

So, I'm happy with the added test case and the fix to make it pass, but I am unsure about all of the other changes.

[gagern]

this PR only changes tests

Nah, this PR also changes documentation. More so since my latest commit. The rest of the changes are just for the sake of consistency, but without these I hadn't spotted the issue about accessors which I had to address to make the whole test suite pass again, and which I included in my doc changes.

[gagern]

I wonder whether Nan::ObjectWrap should provide some combination of Unwrap and dynamic_cast: Something to take an object, check whether it has an internal field, interpret that as a pointer, check whether that pointer is of the expected type, and return the correctly-cast pointer only if all the checks succeed, returning NULL otherwise. Would that make sense for the scenario of using This in a prototype-installed accessor?

[kkoopa]

Doesn't dynamic_cast require RTTI? Node does not have that. Nan::ObjectWrap is just a clone of node::ObjectWrap from newer versions, which adds the persistent() and handle() methods, and in the Nan case changes the type to deal with Nan::Persistents instead. It is preferable to deviate as little as possible from upstream node and V8. When deviations are required, they should preferably be general and not specific and deviate as much as possible. Ideally all or nothing. If you want type checking added, propose it to core first.

Anyway, I think that documentation update was worth the price of the rest of the changes, so I'm happy to merge this.

[gagern]

ObjectWrap does have a virtual destructor, so it has a virtual function table, so it has RTTI. But I can gladly take this to core.

[kkoopa]

IIRC it is explicitly built with -fno-rtti.