I’ve thought for a while now that having variables that are still active, an example being having a variable represent a part and then after destroying that part setting it to nil so that it wouldn’t cause any memory leaks.
Upon part is destroyed, it disconnects its connections. This isn’t 2013 Roblox whereas remove() is the only way then you have to manually disconnect, so you don’t have to worry about it.
Are you sure though? Because when I made a random part and a connection that is the part’s part.Touched connection even after disconnecting it the variable is still equal to the part.Touched connection, so couldn’t this cause a memory leak?
You are talking about the event. I am still unsure whether events declares itself nil on part destroy, but I know the connected events automatically do disconnect itself on part destroyed.
If you call Destroy() on an Instance, the instance will still remain within memory (but, like an earlier reply said, connections will be automatically disconnected).
Well, do you think it would be considered a good practice? And also when you mention “no more references”, do you mean as an example the connection in the touched event after x seconds will be swept up by the garbage collector and become nil after it is disconnected, preventing memory leaks?
e.x
local connection connection = Instance.new("Part").Touched:Connect(function() print("e") end) connection:Disconnect() print(connection) ```
connection is still referenced, it will not make the variable “nil”, but when you’re done using it, it will be garbage collected, you can do a test by using weak tables and putting the connection there, you will see that later the connection on the table will be erased
Disconnect() does NOT set variable to nil. Destroying a variable does NOT set the variable to nil either, as you can still print out properties, as shown below:
It has been explicited multiple times that instances never get completely deleted. What happens when Destroy() is used:
First, the parent is set to nil and the property is locked,
Then events are disconnected,
Eventually, the Destroy() method (or any similar internal method) is called onto children.
They only advise you to set variables to nil so as to not try to modify/access any properties // run any methods on an object that is supposedly destroyed (as you can still access members/properties)
The garbage collection system & scope paradigm take care of your variables. Do not worry about parts being destroyed but not referenced to nil, as the gc will collect dynamically-allocated variables which are no longer referenced in the code at all.
However, you should be careful with tables. Clearing tables (using table.clear() for example) is important, as you may be in a certain condition where the gc cannot collect no-longer-used key:value associations (If I remember well, putting an instance as a key like table[Part] = ..., or setting the value of a key to a function like table[key] = function() ... end can cause memory leaks if not addressed properly.)
That being said, I personally developed a module handling connections (by name), which avoid connection duplicates & memory leaks. I recommend you to do the same.
I also have a tables manager module, whose only purpose is to clear tables when necessary. Remember that {} is a constructor, with dynamic memory allocation. The GC will help you clear those out, but not under all circumstances.