Retrieve the finalizer for an object

[gabrielschulhof]

For objects created using N-API, it would help to have a function to get
the finalizer callback for the value, for example:

napi_get_value_finalizer(napi_env env,napi_value val,napi_finalize*result)

This can be used to determine who created an object, by comparing the
finalizer function pointer (which will be a null pointer if there is no
finalizer callback defined) with the address of the native code's own
functions (there is no point calling the returned finalizer callback).

Re: nodejs/node#14256

Such type-checking can also be accomplished by having the wrapped objects be instances of certain JS classes, and then using napi_instanceof() to decide if a given napi_value containing a JavaScript object has the kind of pointer that is expected.

Are there any other use cases where knowing the identity of the finalizer is helpful?

[gabrielschulhof]

• napi_wrap() – If you wrap an object you receive, then you don't have its class, so you cannot check via napi_instanceof() what kind of object it is. Is this a very common usecase vs. the pattern where the class is created via napi_define_class() and the instances are derived from the class via napi_new_instance()?

• napi_create_external() – If an addon receives externals from the JS side, and especially if it creates externals for differently typed pointers, there is the potential that it will cast to the wrong pointer type, since externals do not have a class from which they can be instantiated and thus a class against which napi_instanceof() can be evaluated.

• napi_create_external_buffer() – this issue does not apply, because the type of the value is not in question - it's a buffer.

• napi_create_external_arraybuffer() - this issue also does not apply, because the type of the value is clear.

In the cases where we might consider adding an API to retrieve the finalizer, if we consider that almost always the native module is fronted by a JS module then that IMO weakens the case for such an API addition, because the native module and the JS module fronting the native module are part of the same package, and therefore under the control of a common entity.

Yet such a mechanism would provide a fail-safe type check.

[mhdawson]

@gabrielschulhof do you think we still need to keep this open? It's been a few years and we've not had any external requests for it.

[mhdawson]

With type tagging this is less necessary and we've not implemented in a number of years so we agreed to close in the Node-api team meeting today. Please let us know if that was not the right thing to do.