gdext icon indicating copy to clipboard operation
gdext copied to clipboard

Separate inputs from proc-macro API and code generation

Open Bromeon opened this issue 1 year ago • 0 comments

Concerns all three proc-macros used for class registration:

#[derive(GodotClass)]
struct MyClass { ... }

#[godot_api]
impl MyClass { ... }

#[godot_api]
impl XyVirtual for MyClass { ... }

At the moment, a lot of those are directly translated to code generation, in the form of the obj::cap traits:

  • GodotInit
  • GodotToString
  • GodotNotification
  • ImplementsGodotApi
  • ImplementsGodotVirtual
  • ImplementsGodotExports

There is not that much reason for many of those to be traits, as we don't really have bounds in our APIs to check those. On the other hand, having all those functions inside separate traits makes it significantly harder to move towards a builder API, as the user needs a lot of boilerplate.

We already have a mechanism to transport information from the proc-macro stage to the registration stage: ClassPlugin + PluginComponent. Since some of the information is code (namely the wrappers for virtual methods, to_string, notifications etc.), it should still be generated by the proc-macro, but maybe in a way that is more compatible with builders. Some ideas:

  • Passing function pointers through ClassPlugin -> could cost us an extra indirection if the linker isn't smart.
  • Still having 3 traits (one for each proc-macro) but combining the code.
    • This would however mean a technical limitations (proc-macros only seeing their own scope) would be imposed on the builder API, too.
  • More?

This could also address #187 properly.

Bromeon avatar Aug 06 '23 14:08 Bromeon