You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* separate out instance-related APIs from `ObjectWrap<T>` into a new
class `InstanceWrap<T>` which then becomes a base class for
`ObjectWrap<T>`.
* Add `Addon<T>` class as a subclass of `InstanceWrap<T>`,
reimplementing `Unwrap()` to retrieve the instance data using
`GetInstanceData<T>()` of `Napi::Env` instead of `napi_unwrap()`.
* Add macros `NODE_API_ADDON()` and `NODE_API_NAMED_ADDON()` to load an
add-on from its `Addon<T>` subclass definition.
Bindings created like this perform slightly worse than static ones in
exchange for the benefit of having the context of a class instance as
their C++ `this` object. This way, they avoid having to call
`info.GetInstanceData<ClassName>()` in the bindings, which brings with
it the risk that the wrong `ClassName` will end up in the template
parameter thus resulting in a hard-to-track-down segfault. Static
bindings can still be created and associated with the `exports` object
and they can use `Napi::Env::GetInstanceData()` to retrieve the add-on
instance.
PR-URL: #749
Reviewed-By: Michael Dawson <[email protected]>
0 commit comments