-
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
n-api: add napi_get_all_property_names #30006
Conversation
a1b77a7
to
af01359
Compare
b75445e
to
e7f6866
Compare
475eddf
to
8e21c82
Compare
doc/api/n-api.md
Outdated
|
||
```C | ||
typedef enum { | ||
napi_key_include_all_properties, |
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.
Would there be any possible ambiguity on these similar naming of napi_key_include_all_properties
and napi_key_all_properties
? IIUC the napi_key_collection_mode
indicates whether or not the keys on the prototype chains are collected, and napi_key_filter
filters property descriptors.
Would it be possible to name napi_key_collection_mode
following v8's pattern? i.e. napi_key_include_prototypes
, which would sound very precise.
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.
I've changed them to napi_key_include_prototypes
and napi_key_include_own_properties
to follow v8's pattern, I think
doc/api/n-api.md
Outdated
```C | ||
typedef enum { | ||
napi_key_include_all_properties, | ||
napi_key_include_own_properties |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
e39c1b9
to
3fcc0c9
Compare
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.
Will be LGTM once the enums are documented.
macOS package notarization and a change in builder configuration The macOS binaries for this release, and future 10.x releases, are now being compiled on macOS 10.15 (Catalina) with Xcode 11 to support package notarization, a requirement for installing .pkg files on macOS 10.15 and later. Previous builds of Node.js 10.x were compiled on macOS 10.10 (Yosemite) with a minimum deployment target of macOS 10.7 (Lion). As binaries are still being compiled to support a minimum of macOS 10.7 (Lion) we do not anticipate this having a negative impact on Node.js 10.x users with older versions of macOS. Notable changes: - buffer: add {read|write}Big\[U\]Int64{BE|LE} methods (garygsc) [#19691](#19691) - build: macOS package notarization (Rod Vagg) [#31459](#31459) - deps: - update npm to 6.14.3 (Myles Borins) [#32368](#32368) - upgrade openssl sources to 1.1.1e (Hassaan Pasha) [#32328](#32328) - upgrade to libuv 1.34.2 (cjihrig) [#31477](#31477) - n-api: - add napi\_get\_all\_property\_names (himself65) [#30006](#30006) - add APIs for per-instance state management (Gabriel Schulhof) [#28682](#28682) - define release 6 [#32058](#32058) - turn NAPI\_CALL\_INTO\_MODULE into a function (Anna Henningsen) [#26128](#26128) - tls: - expose keylog event on TLSSocket (Alba Mendez) [#27654](#27654) - support TLS min/max protocol defaults in CLI (Sam Roberts) [#27946](#27946) - url: handle quasi-WHATWG URLs in urlToOptions() (cjihrig) [#26226](#26226) PR-URL: #31984
macOS package notarization and a change in builder configuration The macOS binaries for this release, and future 10.x releases, are now being compiled on macOS 10.15 (Catalina) with Xcode 11 to support package notarization, a requirement for installing .pkg files on macOS 10.15 and later. Previous builds of Node.js 10.x were compiled on macOS 10.10 (Yosemite) with a minimum deployment target of macOS 10.7 (Lion). As binaries are still being compiled to support a minimum of macOS 10.7 (Lion) we do not anticipate this having a negative impact on Node.js 10.x users with older versions of macOS. Notable changes: - buffer: add {read|write}Big\[U\]Int64{BE|LE} methods (garygsc) [#19691](#19691) - build: macOS package notarization (Rod Vagg) [#31459](#31459) - deps: - update npm to 6.14.3 (Myles Borins) [#32368](#32368) - upgrade openssl sources to 1.1.1e (Hassaan Pasha) [#32328](#32328) - upgrade to libuv 1.34.2 (cjihrig) [#31477](#31477) - n-api: - add napi\_get\_all\_property\_names (himself65) [#30006](#30006) - add APIs for per-instance state management (Gabriel Schulhof) [#28682](#28682) - define release 6 [#32058](#32058) - turn NAPI\_CALL\_INTO\_MODULE into a function (Anna Henningsen) [#26128](#26128) - tls: - expose keylog event on TLSSocket (Alba Mendez) [#27654](#27654) - support TLS min/max protocol defaults in CLI (Sam Roberts) [#27946](#27946) - url: handle quasi-WHATWG URLs in urlToOptions() (cjihrig) [#26226](#26226) PR-URL: #31984
macOS package notarization and a change in builder configuration The macOS binaries for this release, and future 10.x releases, are now being compiled on macOS 10.15 (Catalina) with Xcode 11 to support package notarization, a requirement for installing .pkg files on macOS 10.15 and later. Previous builds of Node.js 10.x were compiled on macOS 10.10 (Yosemite) with a minimum deployment target of macOS 10.7 (Lion). As binaries are still being compiled to support a minimum of macOS 10.7 (Lion) we do not anticipate this having a negative impact on Node.js 10.x users with older versions of macOS. Notable changes: - buffer: add {read|write}Big\[U\]Int64{BE|LE} methods (garygsc) [#19691](#19691) - build: macOS package notarization (Rod Vagg) [#31459](#31459) - deps: - update npm to 6.14.3 (Myles Borins) [#32368](#32368) - upgrade openssl sources to 1.1.1e (Hassaan Pasha) [#32328](#32328) - upgrade to libuv 1.34.2 (cjihrig) [#31477](#31477) - n-api: - add napi\_get\_all\_property\_names (himself65) [#30006](#30006) - add APIs for per-instance state management (Gabriel Schulhof) [#28682](#28682) - define release 6 [#32058](#32058) - turn NAPI\_CALL\_INTO\_MODULE into a function (Anna Henningsen) [#26128](#26128) - tls: - expose keylog event on TLSSocket (Alba Mendez) [#27654](#27654) - support TLS min/max protocol defaults in CLI (Sam Roberts) [#27946](#27946) - url: handle quasi-WHATWG URLs in urlToOptions() (cjihrig) [#26226](#26226) PR-URL: #31984
macOS package notarization and a change in builder configuration The macOS binaries for this release, and future 10.x releases, are now being compiled on macOS 10.15 (Catalina) with Xcode 11 to support package notarization, a requirement for installing .pkg files on macOS 10.15 and later. Previous builds of Node.js 10.x were compiled on macOS 10.10 (Yosemite) with a minimum deployment target of macOS 10.7 (Lion). As binaries are still being compiled to support a minimum of macOS 10.7 (Lion) we do not anticipate this having a negative impact on Node.js 10.x users with older versions of macOS. Notable changes: - buffer: add {read|write}Big\[U\]Int64{BE|LE} methods (garygsc) [#19691](#19691) - build: macOS package notarization (Rod Vagg) [#31459](#31459) - deps: - update npm to 6.14.3 (Myles Borins) [#32368](#32368) - upgrade openssl sources to 1.1.1e (Hassaan Pasha) [#32328](#32328) - upgrade to libuv 1.34.2 (cjihrig) [#31477](#31477) - n-api: - add napi\_get\_all\_property\_names (himself65) [#30006](#30006) - add APIs for per-instance state management (Gabriel Schulhof) [#28682](#28682) - define release 6 [#32058](#32058) - turn NAPI\_CALL\_INTO\_MODULE into a function (Anna Henningsen) [#26128](#26128) - tls: - expose keylog event on TLSSocket (Alba Mendez) [#27654](#27654) - support TLS min/max protocol defaults in CLI (Sam Roberts) [#27946](#27946) - url: handle quasi-WHATWG URLs in urlToOptions() (cjihrig) [#26226](#26226) PR-URL: #31984
Co-Authored-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Backport-PR-URL: nodejs#32482 PR-URL: nodejs#30006 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Co-Authored-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Backport-PR-URL: #32482 PR-URL: #30006 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs#28237 Refs: nodejs#30006
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: #28237 Refs: #30006 PR-URL: #48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs#28237 Refs: nodejs#30006 PR-URL: nodejs#48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs#28237 Refs: nodejs#30006 PR-URL: nodejs#48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs#28237 Refs: nodejs#30006 PR-URL: nodejs#48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs#28237 Refs: nodejs#30006 PR-URL: nodejs#48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs#28237 Refs: nodejs#30006 PR-URL: nodejs#48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs#28237 Refs: nodejs#30006 PR-URL: nodejs#48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: #28237 Refs: #30006 PR-URL: #48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: #28237 Refs: #30006 PR-URL: #48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs/node#28237 Refs: nodejs/node#30006 PR-URL: nodejs/node#48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even though the redefinition complies with the C standard because the second definition is "effectively the same" as the first definition, it's best to avoid any redefinition. Refs: nodejs/node#28237 Refs: nodejs/node#30006 PR-URL: nodejs/node#48879 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
follow up by #28944
support to get all property of an object.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes