:ClearAllChildren() should use :Destroy() and not :Remove()

Feature Requests Engine Features
1

Aurarus wondered about this here, and I checked and :ClearAllChildren() uses :Remove() (or .Parent = nil, but they’re pretty much the same either way) instead of :Destroy(). :ClearAllChildren() should be updated to use :Destroy() as :Remove() is deprecated.

I’m for certain :ClearAllChildren() uses :Remove(). To verify this, add a part to a model in the workspace, and using the command bar, assign that part to a variable. Clear the children of the model and then try to re-parent the part using the variable you assigned it to earlier and it will successfully be moved back to wherever you parented it to.

7 Likes
2

It should be deprecated. We might as well have methods like :SetTransparencyOfAllChildren() which bloat the API

3

why though

4

"why though "

What is :ClearAllChildren() used for? In my case, I’ve used it to depopulate a GUI frame of buttons (hooked up to events) to prepare for re-population and clear all effects in the game (weather, glow, etc hooked up to events) when a user toggles off effects in the settings, and there’s also:

[quote=Malestronomer]Some of my games use ClearAllChildren on 20k parts at a time. I don’t want those in memory at all. [/quote] (source)

I can’t think of any other reason you’d use :ClearAllChildren() other than if you’re getting rid of the children to replace them with something else at some point in time, and if you’re replacing them they’re no longer needed and shouldn’t be hooked up to events.

2 Likes
5

Some of my games use ClearAllChildren on 20k parts at a time. I don’t want those in memory at all.

But they won’t be. Unless you grab a reference to one of the children in Lua.

2 Likes
6

What of the scrolling frame of ~100 image buttons that don’t have references to them but are hooked up to 3 events each? Depopulate and repopulate that frame a couple times and you have 3,000 stray events that haven’t been disconnected. There is absolutely no reason :ClearAllChildren() should use a deprecated method to accomplish its function.

1 Like
7

Hmm, yeah, events will not get disconnected. Which makes me wonder why - in theory GC knows that they aren’t reachable so as soon as the instance dies they should die as well. Maybe we have a circular strong reference in our event implementation or something along these lines.

8

I’m not saying ClearAllChildren() can’t use Destroy(). It probably can. But if GC does not work as-is right now then fixing this may be more important than relying on a crutch.

1 Like
9

Is there a reason to use :ClearAllChildren() rather than a for loop to iterate through so you can use Destroy on each index?

10

Saves you lines of code, and due to the fact that it is part of the API, it can be implemented in C++ rather than Lua. So you probably want to use it if you have to delete a lot of objects at once, for a small amount of objects it probably doesn’t matter which method you use.

3 Likes
11

Remove is deprecated in the first place because it is replaced by ClearAllChildren (and Destroy). If you change this behavior, then Remove stops having a reason to be deprecated. Also, consider that ClearAllChildren was implemented the way it was for a reason, and that changing its behavior can actually break things.

Also note that objects with connected events are GD’d eventually. It just takes an extra step because the events must be disconnected first. You can test it by polling the “connected” property of a RBXScriptConnection.

1 Like