One issue we have is when we are removing/adding a kotlin script to a Godot Object.
On the JVM side, we can end up with 2 different "instances" of the same Godot object, one for the wrapper only manipulating the native pointer and one containing the actual code for the script. When adding/removing a script, the MemoryManager must be able to properly switch from one to another.
To that end, a new middleman was added in Kotlin: GodotBinding, it's managed by the GarbageCollector, now renamed MemoryManager. A reference to it is held by KtObject as well. This is design to reproduce as much as possible the way Godot Objects work in C++.
GodotBinding itself contain reference to both the wrapper instance and the script instance. The binding, wrapper and script create a triangle of strong references so the lifecycle of Refcounted objects still works properly. (For example, the Kotlin code might hold a reference to the wrapper of a RefCounted. Then a script is added on that Refcounted. You naturally want the new script instance to be kept alive if the wrapper is still referenced somewhere.)
I also added tests to check if the right instance is returned after/before changing the script .
piiertho
commented
1 year ago
One issue we have is when we are removing/adding a kotlin script to a Godot Object.
On the JVM side, we can end up with 2 different "instances" of the same Godot object, one for the wrapper only manipulating the native pointer and one containing the actual code for the script. When adding/removing a script, the MemoryManager must be able to properly switch from one to another. To that end, a new middleman was added in Kotlin: GodotBinding, it's managed by the GarbageCollector, now renamed MemoryManager. A reference to it is held by KtObject as well. This is design to reproduce as much as possible the way Godot Objects work in C++. GodotBinding itself contain reference to both the wrapper instance and the script instance. The binding, wrapper and script create a triangle of strong references so the lifecycle of Refcounted objects still works properly. (For example, the Kotlin code might hold a reference to the wrapper of a RefCounted. Then a script is added on that Refcounted. You naturally want the new script instance to be kept alive if the wrapper is still referenced somewhere.)
I also added tests to check if the right instance is returned after/before changing the script .