Add a means to check if the engine (and bindings) is initialized yet

[LikeLakers2]

Hi!

While working on my log crate adapter, I came across the realization that I can't exactly rely on information provided by singletons like OS. The reason: The log adapter may be running before godot_ffi::is_initialized() is true.

While checking what that function returns isn't too hard, it feels weird calling into godot_ffi - not to mention, there's no SemVer guarantee that that function will stay. So perhaps the godot crate could expose it somewhere, such that I can rely on a SemVer guarantee?

For example, godot could expose godot::is_initialized(). This would call into godot_ffi::is_initialized() - or whatever function is appropriate for that version - for us.

[TitanNano]

How would you want to call this function?

Your logger will have to be initialized at some point, right? Initialization logic can be done in unsafe impl ExtensionLibrary for MyExtension {} and the binding will be initialized at that point.

[LikeLakers2]

@TitanNano That's just it - in my situation, I don't (and can't) have an impl ExtensionLibrary.

Specifically, I'm making https://crates.io/crates/gdext-log-adapter, which is meant for use in other projects that already use the godot crate. It's an adapter between the log crate and Godot's logging. However, there's no guarantee that the log adapter will only be used during/after the initialization logic in an impl ExtensionLibrary.

So I have to have a way to check if the engine is initialized, without relying on an impl ExtensionLibrary.

[TitanNano]

Ok, so you want this function to verify your crate is being used correctly? To, e.g. panic if godot::is_initialized() returns false.

[LikeLakers2]

I personally won't be using it to panic, because I can just fallback to printing to stdout/stderr, but yes: I want to be able to know if the engine is initialized, and react accordingly.

[Yarwin]

In our code (for example when checking if we can print or not - https://github.com/godot-rust/gdext/blob/7775e2e77c4d59299ba5f65d22a27868469a2f81/godot-core/src/global/print.rs L162 - exactly the same case) we use is_initialized

gdext/godot-ffi/src/binding/mod.rs

Lines 264 to 267 in 7775e2e

	#[inline]
	pub fn is_initialized() -> bool {
	BindingStorage::is_initialized()
	}

I think it can be exposed without much issue?

[Bromeon]

Could you not just set a global variable (AtomicBool) in impl ExtensionLibrary?

Of course we can expose a function, but technically possible doesn't mean we should. There's a lot of nuance here:

• initialized isn't binary, there are the stages
• the library will be uninitialized again at some point
• "initialized" alone doesn't imply all functionality is available

I want to avoid giving simple answers to complex questions. Different Godot functionality is available at different points in time. Someone operating at a low level where this is relevant should be made aware of the details here -- and the stage init/deinit callbacks in impl ExtensionLibrary are the right abstraction layer for this.

[LikeLakers2]

Could you not just set a global variable (AtomicBool) in impl ExtensionLibrary?

No, I can't. My crate (https://crates.io/crates/gdext-log-adapter) can't have an impl ExtensionLibrary. It's supposed to be used from within other people's gdextensions.

Even if I could have an impl ExtensionLibrary, there's no point to duplicating effort when the godot_ffi crate already knows whether the engine is initialized or not.

[...] Different Godot functionality is available at different points in time. Someone operating at a low level where this is relevant should be made aware of the details here -- and the stage init/deinit callbacks in impl ExtensionLibrary are the right abstraction layer for this.

I really only need the exact same check that godot::global::print_custom() uses to determine whether it should fallback to logging to stderr. Otherwise, I can potentially hit a panic, if I try to check Os::singleton().is_stdout_verbose() before the engine is initialized:

thread 'tests::test_enabled' (3884) panicked at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/godot-ffi-0.5.2/src/lib.rs:573:5:
Godot engine not available; make sure you are not calling it from unit/doc tests
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

All I need is a way to avoid hitting this panic, because a logging adapter should not be causing panics.

[Bromeon]

Otherwise, I can potentially hit a panic, if I try to check Os::singleton().is_stdout_verbose() before the engine is initialized:

So what you need is not really is_initialized but a fallible way to get a singleton.

Think about it like this: it just happens to be that print functionality is available from Core level. If another user needs class X, which is available from Servers level, the whole is_initialized approach is breaking down again. It's why this is not a good API.

[Yarwin]

So what you need is not really is_initialized but a fallible way to get a singleton.

it is the opposite – getting a singleton to check if bindings are initialized is not a solution.

Think about it like this: it just happens to be that print functionality is available from Core level. If another user needs class X, which is available from Servers level, the whole is_initialized approach is breaking down again. It's why this is not a good API.

Hmm, that's compelling argument – we should expose current initialization level instead 🤔.

[Bromeon]

it is the opposite – getting a singleton to check if bindings are initialized is not a solution.

Hmm, that's compelling argument – we should expose current initialization level instead 🤔.

I disagree. We're having a classic XY problem here 🙂

• What the user wants: access class/singleton Y in Godot.
• What the user asks for: whether bindings are initialized, or which stage they are on. (X)
• What the user needs: to know if functionality Y is available. (Y)

Why X is bad: it only gives partial insight, which happens to be enough for this special case because Os singleton has Core level. Even providing current stage is not a good solution; users now need to know which class/singleton is initialized on which stage.

[LikeLakers2]

@Bromeon A fallible method of accessing a singleton would work nicely.

That said, I'm curious how might it be implemented? For example, would we have Singleton::try_singleton()?

I'm also curious if I would need to wait for godot 0.6 for such a thing to be available.

[Bromeon]

That said, I'm curious how might it be implemented? For example, would we have Singleton::try_singleton()?

That's an option, perhaps named singleton_or_null (like Node::get_node_or_null, Node::get_tree_or_null -- on the other hand we also have try_get_autoload_by_name...).

What we need to consider though:

1. There is still Omit the &self parameter for functions on engine singletons #127, which would conflict with this approach.
2. Such an API only tells us if a singleton is available. I could imagine that for other functionality, it would be good to check if a class is available.

So an alternative API would not tie such a check to the Singleton trait but maybe more along:

// bound GodotClass
init::is_class_available::<MyClass>();

// bound Singleton
init::is_singleton_available::<MyClass>();

Maybe in init module directly, which already has similar methods like is_editor_hint or is_main_thread?

---

I'm also curious if I would need to wait for godot 0.6 for such a thing to be available.

No, this should be possible to do as a backwards-compatible addition in 0.5.x.