Could we get a Destroy() that equates Object to nil?

Feature Requests Studio Features
, , ,
#1

I’d like for there to be an option in Destroy on Instances that somehow sets the Instance to nil (override metatable stuff the only make it act like nil, and remove all entries in tables referencing it?). I run in to this a lot when setting up data structures where multiple tables all hold instances, preferably the tables would empty up as the Instances were deleted automatically. Sadly this is not the case, and I end up having to delete the instance, and assign the entry in the table to nil to clear up memory

What I mean by what I want, illustrated in my most common use case:

local Table = {Instance.new(“Part”)}
wait()
Table[1]:Destroy()
print(Table[1]) --> Part
Table[1] = nil – Required to empty the table, an extra line, or at worst, and extra .Changed event
print(Table[1]) --> nil, as desired

if it’s even possible to implement something like this, perhaps do so by passing a bool to Destroy, which defaults to false in whether or not it should nilify itself. Or if you’re not against bloat, a new method wouldn’t hurt.

#2

Can’t you do this with weak tables?

Weak tables don’t register their keys/values with the garbage collector so once your objects disappear from all the other places in your script they should also disappear from the table.

1 Like
#3

I have actually not heard of weak tables, but that’d only solve one half of the coin, it’d also be nice for the Instance to equal nil, as I end up needing twice as many checks to see if the parent is also nil on potentially old variables to tell if an object is destroyed (which nil parent checking may not even be reliable, incase something set it’s parent to nil as opposed to the object actually being destroyed)

Thanks for the suggestion though, I’ll read into it and see if it looks feasible.

Edit: Perhaps I read the docs wrong, but it looked like it just does garbage collection on the table, in this case, Destroyed Instances are still referenced by possibly other variables and tables, so wouldn’t the garbage collection not clear the table of the Instance?

#4

Yeah then I don’t know what could help you.

Maybe set your environment to weak variables lol

I’m not a fan of Destroy automatically making all my references weak. That could have some seriously gnarly consequences.

#5

I’m proposing either an addition to Destroy where you pass it a boolean telling it to nilify, or a new method entirely. I agree that changing the current Destroy would probably cause chaos.

1 Like
#6

It is impossible for Lua to do that - it would take an entire re-write of how Lua references work.

Lua references keep the object alive until it is no longer referenced anywhere - and you can’t set a reference to nil. You can’t even get where the object is being referenced unless you do some stack crawling or something.

The only way around what you’re doing, is, like you said, to use a weak table. This will allow the reference to be garbage collected and removed automatically as it does not actually count as a reference to Lua.

2 Likes
Using instances as keys in a table
Optimal event for running code when a player leaves?
Is there a better way I could do this scoreBoardGui?
#7

As @digpoe mentioned, this is impossible.

You can indeed use weak tables, but if there’s any strong (= non-weak) reference to it, it remains.

You could also just have a function of the Table that you use as Table:Destroy(1), which does what you want.

1 Like
#8

See https://github.com/Anaminus/roblox-bug-tracker/issues/302 for an in-depth discussion.

#9

I thought that :remove() did this.

1 Like
#10

Remove sets the parent to nil – not all variables using the object.

Current behavior:
part = part
part:Remove()
print(part)
> Part

Behavior OP wants:
part = part
part:Remove()
print(part)
> nil

#12

…

how? or why?
I mean, you could on the C-side go trough all locals and tables and delete references to it, but eh…
It’s probably better if OP learned weak tables…

#14

By editing the core mechanics of Lua?

#15

A business will do what their clients want. It’s how they make money.

#16

No, it means that they don’t know what weak tables are and don’t know that blindly killing strong references will lead them into an endless series of very awful debugging sessions.

Let’s put it this way: In order to use such a feature correctly, you have to be very aware of where objects are located in your program, at which point you might as well just handle them without the feature.

4 Likes