You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi!
I would say I'm pretty new to the Godot engine, but as someone interested in memory management and language interop, I noticed something I really dislike. As far as I can see, calling the constructor new GodotObject() allocates a C++ Object implicitly. Said Object is not freed when GodotObject gets garbage collected. This breaks both allocation-free parity, and C# convention. This applies to all objects which inherit from Object/GodotObject.
This would entail major wide-reaching breaking changes in how C# bindings are used, but the changes themselves are relatively simple and they would solve this issue:
Create a GodotObject.New() static factory method. It behaves identically to how new GodotObject() behaves currently. This looks closer to how GDScript instantiation looks and restores allocation-free parity with Free().
new GodotObject() is either deleted, made protected, or if that is impossible due to inheritance issues, instantiates a GodotObject in a similar state to how instances behave after Dispose() is called on them. These instances would be effectively useless and throw on nearly all actions.
Because of the fact that a C++ object is never directly tied to the C# garbage collector, we (and thus the documentation) should not treat the C# classes as drop-in replacements to Objects. What they are, are adapter patterns. They attach themselves to C++ classes and forward all communication through FFI. The fact that the C# structure can outlive the C++ structure shows it cannot be a drop-in replacement.
I would love to hear your opinions on this and maybe if this gains enough support, I or someone more knowledgeable than me could take a deeper look and make a proper proposal.
The great thing is that this doesn't necessarily need to be a breaking change immediately. All we'd need to do is do the first part and mark using the default constructor as a deprecated or discouraged approach and warn of the consequences. Then remove it in a breaking way after a few versions to hopefully make the transition easier.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi!
I would say I'm pretty new to the Godot engine, but as someone interested in memory management and language interop, I noticed something I really dislike. As far as I can see, calling the constructor
new GodotObject()
allocates a C++Object
implicitly. SaidObject
is not freed whenGodotObject
gets garbage collected. This breaks both allocation-free parity, and C# convention. This applies to all objects which inherit fromObject
/GodotObject
.This would entail major wide-reaching breaking changes in how C# bindings are used, but the changes themselves are relatively simple and they would solve this issue:
GodotObject.New()
static factory method. It behaves identically to hownew GodotObject()
behaves currently. This looks closer to how GDScript instantiation looks and restores allocation-free parity withFree()
.new GodotObject()
is either deleted, madeprotected
, or if that is impossible due to inheritance issues, instantiates aGodotObject
in a similar state to how instances behave afterDispose()
is called on them. These instances would be effectively useless and throw on nearly all actions.Because of the fact that a C++ object is never directly tied to the C# garbage collector, we (and thus the documentation) should not treat the C# classes as drop-in replacements to
Object
s. What they are, are adapter patterns. They attach themselves to C++ classes and forward all communication through FFI. The fact that the C# structure can outlive the C++ structure shows it cannot be a drop-in replacement.I would love to hear your opinions on this and maybe if this gains enough support, I or someone more knowledgeable than me could take a deeper look and make a proper proposal.
The great thing is that this doesn't necessarily need to be a breaking change immediately. All we'd need to do is do the first part and mark using the default constructor as a deprecated or discouraged approach and warn of the consequences. Then remove it in a breaking way after a few versions to hopefully make the transition easier.
Beta Was this translation helpful? Give feedback.
All reactions