Skip to content
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

JsBox #561

Closed
dherman opened this issue Jul 24, 2020 · 4 comments
Closed

JsBox #561

dherman opened this issue Jul 24, 2020 · 4 comments

Comments

@dherman
Copy link
Collaborator

dherman commented Jul 24, 2020

This is a placeholder issue for now until we have an RFC.

We should consider a simpler primitive than classes for sharing Rust data structures with JavaScript and back again. A couple years ago, @matklad proposed the idea of a JsBox primitive, which would be a basic building block for sharing Rust data with JS, around which you could define custom JS classes mostly in pure JavaScript.

Another interesting development: infinyon/node-bindgen has done some great innovation on auto-generating JavaScript classes with a procedural macro, as opposed to the old-style macro_rules macro of our class system. I think that's a better direction in the long-term, but it could potentially build on JsBox as an underlying primitive.

And in the medium-term, I think we could use JsBox to experiment with pushing the class macro out into a third-party library and get it out of Neon proper. That would clear a path to prevent us from getting stuck permanently with a 1.0 release on a macro that was clearly never fully baked.

@dherman
Copy link
Collaborator Author

dherman commented Jul 24, 2020

@kjvalencik
Copy link
Member

kjvalencik commented Jul 24, 2020

@dherman Interestingly the pattern explained in that comment (simple classes that are only used for wrapping and get passed as the first argument to functions) is exactly the pattern I fell into. This pattern is also beneficial for factory classes instead of initializing data with an Option.

@kjvalencik
Copy link
Member

Notes from investigation:

  • std::any::Any does most of the hard work of type tagging and downcasting.
  • std::any::type_name allows generating nice informative TypeError. E.g., TypeError: Failed to downcast to "my_crate::MyStruct"
  • napi_create_external provides the required functionality. However, it does not currenty support external tags. Undefined behavior would result if the user passes in an external from another library.
  • Needs to be double boxed since N-API will only has space for a thin pointer
  • Should this use the existing borrow API or should we tie it to Context borrows?
  • This combined with the upcoming Persistent RFC are capable of replacing both the Task and EventHandler APIs.

@goto-bus-stop
Copy link
Member

For reference, the RFC is here: neon-bindings/rfcs#33

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants