-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
node-api: add napi_get_symbol_to_string_tag()
#41370
node-api: add napi_get_symbol_to_string_tag()
#41370
Conversation
Fixes: nodejs#41358 Signed-off-by: Darshan Sen <darshan.sen@postman.com>
Review requested:
|
Hi @RaisinTen! Great work, and especially fast for a holiday season, so thank you very much! This PR is perfect for me, but while you made this, I realized it would be nice to add the other "well-known Symbols" specified by ECMAScript as well, as it may be requested in the future. https://tc39.es/ecma262/#sec-well-known-symbols
So instead of napi_status napi_get_symbol(napi_env env, napi_symbol_name name, napi_value* result) And under the "Structures" section: typedef enum {
napi_symbol_async_iterator,
napi_symbol_has_instance,
napi_symbol_is_concat_spreadable,
napi_symbol_iterator,
napi_symbol_match,
napi_symbol_match_all,
napi_symbol_replace,
napi_symbol_search,
napi_symbol_species,
napi_symbol_split,
napi_symbol_to_primitive,
napi_symbol_to_string_tag,
napi_symbol_unscopables
} napi_symbol_name; This is a minor modification: just rename the function and add a switch/case inside. It will be much cleaner for the API, what do you think? |
napi_get_symbol_to_string_tag()
napi_get_symbol_to_string_tag()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What’s the problem with getting these symbols of the global Symbol
variable? Obviously we could do what this PR suggests, but that seems like a slippery slope to adding getters to the Node-API interface for every single JS builtin.
Can we access the global (OP is here: #41358) |
Yes, and that is would I would indeed suggest :) |
How is that wrong? We already have APIs like
when just napi_throw() would be enough. Also constructors like
are not needed if we can just call napi_new_instance() on the constructors that can be accessed on the global object. |
Well … that’s also true for JS code which references
Well – If you want convenience, you probably won’t use C to begin with. And as shown in that thread, in the C++ convenience wrapper API, it’s a one-liner. That being said, of course it’s nice to have a helper API for this in C as well – but that doesn’t mean it has to be in the core Node-API. Somebody (e.g. you) could just publish a header library to npm which provides this. (I’ve done that in the past for other things, and it works just fine, e.g.
That’s true, but I wouldn’t consider performance a concern. If it is, people can cache the value in their addons.
Great point! I should have argued against adding these specific methods when Node-API was being introduced. (That being said, I assume part of the motivation here was matching what the V8 API provides out of the box.) |
Looks like #41358 was closed with an alternate solution. Should this be closed? |
Concerning my issue #41358, I'm fine with the solution proposed by @addaleax. |
@mhdawson the OP might still benefit from what's exposed from this PR / the |
@RaisinTen this is the guidance we have - https://github.com/nodejs/node/blob/master/doc/guides/adding-new-napi-api.md As mentioned by @addaleax it still does often come down to a grey line. I'm ok with #41329 landing as it seemed more limited in scope, while this one seemed to grow the scope beyond the spirit of |
Thanks for the clarification, closing :) |
Fixes: #41358
Signed-off-by: Darshan Sen darshan.sen@postman.com