Expose NOTIFICATION_EXTENSION_RELOADED to ClassDB

[EterDelta]

Currently, the extensions reload notification lacks of ClassDB binding in the Object class.
This prevents it from being generated in the bindings, which doesn't make sense since it was introduced to be used by extensions in the first place. (#80284 (comment))

Something that stands out in that discussion is whether it should be removed, as there are no real world use cases.
But in fact there are! We can take a look at how engine classes like Bone2d cache parent pointers when entering the tree. These cached pointers are also used for editor tasks, like configuring warnings.
This would be imposible without the reload notification in an extension, as everytime we hot reload, the pointers become dangling, causing us to lose track of whatever we were pointing to in the editor.

[dsnopek]

Yes, I agree this should be exposed!

I'd mark it as approved, but it looks like it needs a docs update to pass CI.

[Mickeon]

Right off the bat, while exposing it is probably a good idea, it being among both NOTIFICATION_POSTINITIALIZE and NOTIFICATION_PREDELETE definitely stands out like a sore thumb... It is useful, but it is not useful every day, so to speak? I'm a bit wary of that.

If it is agreed that exposing the constant is fine, then I would see no reason to keep NOTIFICATION_PREDELETE_CLEANUP hidden, either.

[dsnopek]

In this case, NOTIFICATION_EXTENSION_RELOADED is meant to be used by GDExtensions, but the code generation used in most (all?) GDExtension bindings won't know to generate if it's not exposed. I suppose they can still use it by referring to the integer value? In any case, the point I'm trying to make is that this was added in order to be exposed to GDExtension, there's no use for it in core itself :-)

[Mickeon]

I see, well... In that case it's fine. I just wish we didn't have to document it in full display like this.
Autocompletion would always show it, even if it can really only be used for GDExtension. It's among a few things that contribute to bloat.

It could be defined in the GDExtension class, couldn't it? ProjectSettings does something similar.

[dsnopek]

It could be defined in the GDExtension class, couldn't it? ProjectSettings does something similar.

Do you have a reference to the ProjectSettings thing?

We could manually define it in godot-cpp without exposing it. But that won't help any of the other bindings, they'd all have to manually define it too (whereas exposing it the normal way it'll just get picked up by the code generation).

[EterDelta]

I mean, its usage can extend beyond just GDExtension. 🤔
As I wrote in the doc, derived classes also get notified, that includes scripts.
So, maybe tool scripts that extend extensions classes could implement some custom synchronization that needs to be notified each time the parent reloads.

[Mickeon]

Do you have a reference to the ProjectSettings thing?

Sorry, I actually meant EditorSettings. Important distinction

What I do mean is, just because it is received by every Object does not mean it needs to be defined in Object. EditorSettings notifies NOTIFICATION_EDITOR_SETTINGS_CHANGED to everything in the tree, and editor nodes answer accordingly. For example:

godot/editor/project_manager.cpp

Lines 107 to 112 in 9adb7c7

	case EditorSettings::NOTIFICATION_EDITOR_SETTINGS_CHANGED: {
	if (EditorThemeManager::is_generated_theme_outdated()) {
	_update_theme();
	}
	_update_list_placeholder();
	} break;

[dsnopek]

Hm. Well, I guess we could do that. Personally, I prefer having it on Object because I feel like GDExtension is very much a part of Object, however, I'm clearly biased. :-) I'll defer to whatever the @godotengine/core team thinks is best!

[akien-mga]

Makes sense to me that it's exposed in Object.

[akien-mga]

Thanks!

[akien-mga]

Cherry-picked for 4.2.2.