Access to ScriptServer

[Kehom]

Godot version

4.3 beta 2

godot-cpp version

master

System information

Windows 10 and Linux Mint

Issue description

If implementing a module, we can include the script_language.h file then access ScriptServer. However this is not exposed to GDExtension. I don't know if there is a reason for that.

That said, there are a few things that are very useful. Of particular interest to me is querying if a scripted class inherits from a specific base. I know that we can manually do that by first obtaining the list of "global classes" (ProjectSettings::get_singleton()->get_global_class_list(). However this option means that we always have to iterate through the list of classes. Caching the data might result in outdated data. From my understanding ScriptServer is always updated whenever a scripted (global) class is created or removed.

I understand if not exposing ScriptServer is actually desired.

Steps to reproduce

Minimal reproduction project

[Kehom]

Err.. Quite frankly I didn't know if it was exactly a bug or a feature proposal because we can include script_language.hpp, albeit the class in there only contains the ScriptNameCasing enum.

That said, sorry if this was indeed meant to be a feature proposal.

[AThousandShips]

I think it's intentional to give access to the relevant code, but let's see what the feedback is, my bad!

[dsnopek]

Whether or not to expose ScriptServer the usual way is more a question for whoever is responsible for the Scripting API, rather than something for the GDExtension team to decide.

However, it does appear as though ScriptServer is not exposed the normal way on purpose: if it were, then GDScript (or other scripting languages) could interact with it, which seems undesirable.

So, assuming we don't want to expose it in the normal way, we could add some new functions to gdextension_interface.h in order to access it, and then in godot-cpp make a wrapper class that mimicks the API of ScriptServer?

[Kehom]

I do believe ScriptServer should not be exposed to GDScript. That said, since the intention of GDExtension is to have parity with Modules, then I do believe we need some sort of access to that server. So indeed, not exactly the "normal way".