Repository: godotengine/godot-cpp (C++)

Issue:
Object does not dispatch NOTIFICATION_POSTINITIALIZE 
### Godot version

4.2

### godot-cpp version

4.2

### System information

Windows 11

### Issue description

When a custom resource is defined, such as:
```
class MyResource : public Resource {
  GDCLASS(MyResource, Resource);
};
```

The `_notification` method is never dispatched with NOTIFICATION_POSTINITIALIZE like it is in Godot / GDScript.

### Steps to reproduce

Create `MyResource` as outlined above using:
```
Ref<MyResource> r;
r.instantiate();
```
or using `memnew`
```
MyResource *r = memnew(MyResource);
```
In neither case is the NOTIFICATION_POSTINITIALIZE fired.

### Minimal reproduction project

N/A


Discussion: Thanks!

I'm not 100% sure if this should be handled on the godot-cpp side or on the Godot side, so this will need some investigation and discussion.
That's reasonable, hopefully, it's something we can get into 4.2 :)
Hi @dsnopek, I'm curious if you have had a chance to see what the impact/effort is for this?
Well, it's really simple to fix on the godot-cpp side - I think it'd just be adding one line of code. :-)

But what I need to look into is if it's possible/desirable to fix this on the Godot side instead. If we can fix it on the Godot side, then all bindings will be fixed, rather than each having to do their own fix for this issue.
Discussed at the GDExtension meeting, and we favored having the GDExtension bindings dispatching `NOTIFICATION_POSTINITIALIZE` (rather than having the engine attempt to do it automatically), since there isn't a good place to do it that wouldn't have potential issues. For example, we discussed having `Object::set_instance_binding()` do it, but developers wouldn't necessarily expect that function to have side effects, and in some language bindings, they might not be finished initializing the object at that point. This does mean that we would need to document that all language bindings need to do this.

It would be helpful to have more feedback from other language binding maintainers, /cc @Bromeon 
I guess that makes sense, and I'm fine with the extension dispatching `NOTIFICATION_POSTINITIALIZE`.

But how do people learn about this? Where would be a good place to document it?
Without seeing this issue, I'd likely never have known this is something we should do 😉 
We probably need a "how to create GDExtension bindings" document, but that'll be a tricky thing to start given that there's so much to write and we probably can't get it all in one pass. Maybe it could be a "tips for creating GDExtension bindings" first?



Fix (patch):
diff --git a/src/classes/wrapped.cpp b/src/classes/wrapped.cpp
index 37fcf65a6..ad0eefb10 100644
--- a/src/classes/wrapped.cpp
+++ b/src/classes/wrapped.cpp
@@ -50,6 +50,12 @@ void Wrapped::_postinitialize() {
 		godot::internal::gdextension_interface_object_set_instance(_owner, reinterpret_cast<GDExtensionConstStringNamePtr>(extension_class), this);
 	}
 	godot::internal::gdextension_interface_object_set_instance_binding(_owner, godot::internal::token, this, _get_bindings_callbacks());
+	if (extension_class) {
+		Object *obj = dynamic_cast<Object *>(this);
+		if (obj) {
+			obj->notification(Object::NOTIFICATION_POSTINITIALIZE);
+		}
+	}
 }
 
 Wrapped::Wrapped(const StringName p_godot_class) {