src: officially deprecate node::ObjectWrap#63756
Conversation
|
Note that this class is mentioned extensively in |
This interface has long been unmaintained and doesn't match current best practices for C++ object management. It's also simply not a good idea to have this header be part of Node.js core; since it is an inline header, user code will depend on the Node.js version it was compiled with, and there is no way to adopt changes to this header independently of changing the target Node.js version. Better userland alternatives exist and have long been more popular, notably, `node-addon-api` and, for use cases where direct V8 API access is required, `nan`. Signed-off-by: Anna Henningsen <anna@addaleax.net>
f19268a to
450d97a
Compare
|
@Renegade334 Thanks for pointing this out! Can't really believe we seriously recommended this 🙃 I've added changes to account for this in 450d97a – went back and forth on the approach a bit, but ultimately decided that it would be most helpful to just include a trimmed-down copy of the class in our docs. @ronag @legendecas You may want to re-review this since there's a fairly large addition now compared to the original change |
|
Landed in d097de8...fc28d94 |
This interface has long been unmaintained and doesn't match current best practices for C++ object management. It's also simply not a good idea to have this header be part of Node.js core; since it is an inline header, user code will depend on the Node.js version it was compiled with, and there is no way to adopt changes to this header independently of changing the target Node.js version. Better userland alternatives exist and have long been more popular, notably, `node-addon-api` and, for use cases where direct V8 API access is required, `nan`. Signed-off-by: Anna Henningsen <anna@addaleax.net> PR-URL: #63756 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
This interface has long been unmaintained and doesn't match current best practices for C++ object management. It's also simply not a good idea to have this header be part of Node.js core; since it is an inline header, user code will depend on the Node.js version it was compiled with, and there is no way to adopt changes to this header independently of changing the target Node.js version. Better userland alternatives exist and have long been more popular, notably, `node-addon-api` and, for use cases where direct V8 API access is required, `nan`. Signed-off-by: Anna Henningsen <anna@addaleax.net> PR-URL: nodejs#63756 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
|
What is the recommended alternative for embedders? I just stumbled upon this API today after writing a majority of it independently and found it to be much more robust than anything I was going to do. Considering that this class is exactly what I need, I was about to just copy-paste this into my project and move on, but "legacy", "not intended to be used by new code", "can't really believe we seriously recommended this" are enough for me to ping here and see if there's something more appropriate that I'm overlooking? edit to clarify: neither |
This interface has long been unmaintained and doesn't match current best practices for C++ object management.
It's also simply not a good idea to have this header be part of Node.js core; since it is an inline header, user code will depend on the Node.js version it was compiled with, and there is no way to adopt changes to this header independently of changing the target Node.js version.
Better userland alternatives exist and have long been more popular, notably,
node-addon-apiand, for use cases where direct V8 API access is required,nan.