EntryPoint Cleanup

[samdeane]

The entrypoint code is a bit messy currently.

There are currently three places (that I know of), which do approximately what initializeSwiftModule does:

• initializeSwiftModule itself
• runGodot in SwiftGodotKit
• runGodot in SwiftGodotTestability

I think it ought to be possible to refactor the latter two do just be something along the lines of:

let ih = // our specific init hook code
let dh = // our specific deinit hook code
let mil = // our minimum level
libgodot_extension_bind { g, l, e in
    initializeSwiftModule(godotGetProcAddPtr: p, libraryPtr: l, extensionPtr: p, initHook: id, deInitHook: dh, minimumInitializationLevel:mil)
} _: { startup in
    if let cb = loadSceneCb, let ptr = startup {
        cb (SceneTree.createFrom(nativeHandle: ptr))
    }
}

This would eliminate some repetition in one of the gnarlier bits of code, which I think would be a GoodThing™.

Furthermore, currently we are not really using the userData pointer in the extension struct.

Or rather, we are setting it to a copy of the library pointer, and then using that as an index into tables containing our callbacks.

Rather than doing this, I think we should have an actual GodotExtension class.

When we register the extension we should make an instance of this class, and pass an opaque pointer to the instance as the userdata.

This will allow us to retrieve the instance in the static callback functions, and dispatch to that instance.

This in turn will allow the instance to just keep references to its callbacks, rather than needing a table.

The default behaviour of the #entrypoint macro would simply be to make an instance of GodotExtension and call into it, passing the pointers it had been given. This would do what initializeSwiftModule does now.

SwiftGodotKit and the GodotRuntime tests would do a similar thing, from within the callback from libgodot_gdextension_bind.

For situations where some custom behaviour was required, the user could subclass GodotExtension and override parts of it.

I think that this would allow us to remove the need for the ExtensionInterface as a separate protocol - the customization points that it provides could just be methods on GodotExtension.

We could also move the Swift-ified version of InitializationLevel into GodotExtension

[samdeane]

I'm thinking of doing this work, but wanted to run it by people first.

I realise that there may be other use cases like Xogot or the migeran multiple-views effort; I can't see any reason why what I'm proposing wouldn't work (and/or help) with these, but I don't want to collide badly with those efforts.