-
Notifications
You must be signed in to change notification settings - Fork 210
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
Separate static name from NativeClass
into new trait
#847
Conversation
This allows NativeScript types to be registered under names only determined at run time, enabling better ergonomics for libraries. Ref godot-rust#601, godot-rust#603
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.
Thanks a lot for this great PR!
You bring up a good point with too many attributes. I agree it might be better to scope them appropriately.
bors try
tryBuild succeeded: |
cfe0f6f
to
fecf465
Compare
I tried the changes with a local project, all seems good. If there is no more feedback/addendum, I can merge this tomorrow. |
I don't have further feedback myself at the moment. #848 should be best done as a separate PR, I believe. |
bors r+ |
Build succeeded: |
This allows NativeScript types to be registered under names only determined
at run time, enabling better ergonomics for libraries.
Ref #601, #603
Unresolved questions
This does not implement the
#[name = "MyCustomName"]
static renaming syntax as suggested in #601 (comment), because it's very uncommon (if at all possible) for a key-value pair to be the top-level meta in an attribute. It should also be noted that at this moment, theNativeClass
macro already utilizes a large number of type-level attributes:inherit
user_data
register_with
no_constructor
...so it might not be wise to add another into the mix, especially under such a non-specific identifier as
name
. We might want to consider bundling (some of) these into a single top-level attribute (likevariant
for theFrom
/ToVariant
macros) instead. See #848.