-
Notifications
You must be signed in to change notification settings - Fork 285
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
Comments
Here is @matklad’s comment about the |
@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 |
Notes from investigation:
|
For reference, the RFC is here: neon-bindings/rfcs#33 |
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 onJsBox
as an underlying primitive.And in the medium-term, I think we could use
JsBox
to experiment with pushing theclass
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.The text was updated successfully, but these errors were encountered: