Open gabrielschulhof opened 6 days ago
Re #1514
@gabrielschulhof ,
I really like the qualifier of "basic" for the env.
... basic conveys the idea that fewer things can be done when you only have a "basic" environment ...
Makes sense to me!
... since folks might be familiar with the base class/subclass relationship ...
And this paradigm goes well with the work we'll do in node-addon-api to incorporate the sync finalizers.
@gabrielschulhof , regarding finalizers:
void my_sync_finalizer(node_api_basic_env env, void* data, void* hint);
void my_regular_finalizer(napi_env env, void* data, void* hint);
eg. for documentation, would you say that a finalizer can be categorized as either a "synchronous" finalizer or a "regular" finalizer? Perhaps it's better for "synchronous" or "asynchronous"?
Following up on our discussion during the meeting, let's jot down the possible names we'd like to use instead of
env
andnogc_env
. Here are the scenarios I can think of so far:Inspired my Michael's emphasis that we're dealing with a base class - subclass relationship, I was thinking,
since
basic
conveys the idea that fewer things can be done when you only have a "basic" environment, and since folks might be familiar with the base class/subclass relationship, whereby if a function accepts a base class then one can pass either, whereas if the function accepts a subclass and one only has a base class handy, then the function is off-limits.We also need not necessarily elaborate on why an environment is basic. The fact that the context of being in a sync finalizer and therefore unable to manipulate engine heap is the reason why some APIs are off-limits is something we can document, but not absolutely necessarily.
WDYT?