Tristan Grespinet

I agree with .2 and .3. .1 is a more delicate matter because you actually don't always want to register a child class of a Godot type to the Engine....

Regarding marking class that inherit Godot type as abstract so they are not registered: This wouldn't work. We don't support the feature yet, but Godot allows registering Abstract scripts too...

By the way, if we go along with a more implicit option. Shouldn't we take the opportunity to rename the main annotation to something like `@GodotScript `instead of `@RegisterClass`, it...

I'm not up for that feature being an external plugin. It seems core enough for me. And like the Cedric said, maintaining it is just a matter of a few...

Sorry, I couldn't understand your explanation about the current situation being implicit already. We wish for some side effect (here registering a class) so we have some syntax for it,...

Custom getters and setters are currently supported, but of course, their types has to be Godot-compatible . We don't support "val" yet but Godot recently added a `read-only` flag for...

By the way, should we take the opportunity to rename some annotations? Like` RegisterClass` could become `GodotScript`, for the sake of being clear this is related to Godot.

It at least tells us it's related to deleting a global ref from the c++ side, and if it rarely and randomly happens, it means it's a race condition. Most...

It's very unlikely to be your mistake, users code is not supposed to have any influence on how the module handle the JNI ref. It's random because it's probably a...

I already checked how C# does it and actually, the second point of my proposal is to move away from the way C# is managing its memory (because we are...