RFC: add pyo3-like attribute macros to define nodejs classes and methods

[Mossaka]

Signed-off-by: Joe Zhou jiazho@microsoft.com

[kjvalencik]

Thanks so much for this proposal! Py03 is a great example because a lot of the problem space are shared.

[kjvalencik]

I think these should be namespaced to help prevent conflicts with other macros. This could be named neon::class_methods or we could have everything in a neon::class module.

#[neon::class::data]
#[neon::class::methods]

[Mossaka]

Currently neon only has one proc/attribute macro, right? main

[kjvalencik]

That's correct.

[Mossaka]

I actually prefer the simplicity of #[neon::methods], #[neon::classes] if in a foreseeable future there won't be any namespace conflicts.

[kjvalencik]

The current declare_types macro has a two-part initialization with the second part being optional.

1. (Required). Constructor. This creates the Rust struct that gets wrapped into the JS class.
2. (Optional). Initialization. This has access to the created class and can perform actions like assigning properties. This can be thought of as using this in a JS constructor.

I think this is valuable and it would be nice to maintain that functionality. I can think of a couple ways to implement it:

1. Another macro attribute like #[neon::class_init] for that phase
2. Need to call a function and return a class instead of the data type.

create_class(Person { name, age })

[kjvalencik]

Some unresolved questions that I have.

1. What is the name of the type? Do we generate complete new types or do we have something like JsClass<Person>?
2. Do we implicitly create a RefCell or do we only allow &self? I think we should start simple and class methods can only take &self. If they take a different form of &self we fail to compile and if they don't take self at all we create a static method.
3. Are there any other critical features? In my opinion we should start simple and not try to add everything.
4. What happens if the class is called as a function instead of a constructor?

[Mossaka]

Updated RFC with the comments.

[esatterwhite]

Would love to see this added back. Very much missing it from the recent versions

[louneskmt]

Any update on this RFC?

[kjvalencik]

@louneskmt No update. This RFC itself is blocked by being able to create classes (i.e., a type safe wrappers around napi_define_class and napi_wrap).

While this feature is highly desirable, it's not considered a blocker for Neon 1.0 because the functionality can be accomplished with some JavaScript glue code. Blockers for 1.0 have taken priority.

Contributions would be welcome. I have spent a bit of time thinking about what Neon's napi_define_class might look like. Most likely:

• A trait providing a constructor, name, and properties
• An instance data cache that can lookup constructors based on the implementing type
• Some code for wrap/unwrap that operates similar to JsBox