Code:
-- somewhere at the top, assign a table to a variable
local T = {}
-- somewhere, make a tween
T[A] = tweenobj
-- somewhere else, want the previous A to get out so I can use a new A
A:Cancel()
A:Destroy()
A = nil
-- slightly below above, do my thing
A = newtweenobj
Query:
Often at times, I cache Tween objects into table if I need to operate on them in the future (such as overriding and cancelling tweens to play another one over top). In such a case, I do three things in order:
- Cancel the tween
- Destroy the tween
- Set the indice to nil
Do I really need to do this? I feel like what I’m doing is unnecessary and I don’t understand when or why I started doing this in the first place.
Calling :Destroy() on a Tween has never worked for me. Setting it to nil is sufficient enough.
Although it is not required to set it to nil if you’re going to replace it with a new tween.
1 Like
TweenObjects are Instances, so Destroy can be called on them. Destroy is a method of the Instance superclass in which all instances inherit from (obviously). Destroy is intended to disconnect all connections from the Instance and parent it to nil, where it can be garbage collected. You typically should be destroying all instances you do not need.
My question is whether I need to do all three of these things or not. I can most likely skip Destroy since no connections are being made; it’s just the caching and potential memory leak that is of concern.
“Although it is not required to set it to nil if you’re going to replace it with a new tween.”
Is this an implication that the previous value is set to nil if the variable is overwritten? My knowledge on variable overwriting is antiquated. I always clean up my previous variable before overwriting, if its a userdata.
If the variable is overwritten the previous value does not exist anymore. Which is equivalent of setting it to nil.
Memory Leaks would be my only concern as well. However in my testing of if setting them to nil causes a leak didn’t provide clear results to me. I didn’t notice any leaks, and is something that’d probably require more thorough testing to provide a more clear answer.
1 Like
Fair enough. I’ll mark the first post as the solution since the ensuing conversation was asking for elaboration. I figured as such, three times over is a little much.