I appreciate you for contextualizing this.
I’m reminded that I need to be more careful when making objective/declarative statements.
I don’t precisely understand what you’re suggesting when you say that the RefCounting is cyclic, or more specifically how that would be an issue in this situation. I have the most experience writing code in Java, which has its own GC, so it’s true I never had to worry about memory management. I’m guessing this “cyclic” problem is some kind of provable mathematical truth that I haven’t quite wrapped my head around.
This confusion might be related to my having misspoke or poorly communicated what I was trying to accomplish.
I don’t know how Godot’s
load()
function is implemented internally, but according to the documentation it will somehow be able to either clone() or otherwise retrieve the packed scene/resource in memory if it exists.
Assuming this works correctly, I don’t actually need a reference to the object at all.
I just need it to exist in memory, so that I don’t have to retrieve the script from disk every time.
When I want to clone it, I just call
load("some_resource.gd")
and because it’s instanced in memory somewhere, it clones it instead of getting it from the disk.
That object could then have some kind of “kill signal” that it listens for so that when the data structure using it as a template to copy from doesn’t need it anymore, it can
func _on_kill() -> void:
self.free()
Again, I’m not suggesting this would be an ideal solution. I would hope that with some careful thought I could think of something better.
Even so, I hope this clears up my imagined use case. I don’t want an explicit reference because the idea is that I don’t know what objects I will need at compile time. I could also just feed them into a dictionary but that seems like a waste of processing, while admittedly being relatively cheap.
At the end of the day it’s kind of moot since I went with a different approach anyway, but I do think this is technically interesting