It’s very frustrating, especially with UI constraints, using :ClearAllChildren() on UI, and it to delete everything, when you only want the frames, textlabels and stuff to be removed. It’d be neat if I could write
UI:ClearAllChildren("UIListLayout")
And it’d remove everything apart from UIListLayouts.
I’ve had repeated times when I’ve had this bug, and it’s really confused me as to why all my stuff formatted nicely the first time, but the second time it was just broken.
Ideally it should be a table for multiple elements if needed.
If ya want it cleaner merge this with Generalizing Whitelists/Blacklists for huge API performance gains
and you have a nice all in one solution.
You’d just add multiple arguments?
UI:ClearAllChildren("Class1", "Class2", "Class3") -- etc ad infinitum
A table is a much cleaner solution than multiple arguments and is more in line with the ROBLOX API.
A table would be less clean, but it’s literally the same thing with extra notation?
It seems like the ROBLOX API uses tables to take in a collection more-so than tuples. In fact, I can’t think of anywhere where tuples are used as inputs to any ROBLOX API method. Are there any?
I feel indifferent about both.
Lua doesn’t allow more than 8000 arguments, so tables are just generally better to use across the API. If you wanted less notation you could still write this, which is valid lua:
UI:ClearAllChildren{"Class1", "Class2", "Class3"}A :ClearAllChildrenOfCondition() method would fit perfectly
Print?
That’s a built-in Lua function though. I did end up finding a few that take tuples though, like FireClient.
I think that logically, it doesn’t make sense for :ClearAllChildren({ ... class names ... }) to clear all children except the specified classes. The naming of the method would lead the user to presume the specified class names are the only ones that would get cleared.
I brought up a suggestion when I was an intern to make those constraints an adornee option. Because it is indeed very obnoxious now having to do getChildren() on a GUI and looping through it to remove constraints or adding all its objects into a table when the created. Same issue with ClearAllChildren(). I didn’t have all the details planned out but it would be nice to not have to parent UI constraints to GUIs necessarily. Somewhat related to your post I think.
I spoke with @darthskrill about this when using many constraints for an internal project during my internship.
He proposed a method that is called on a layout to destroy all elements being controlled by the layout which sounds like a step in the right direction, if not the solution.
Not a very strong case considering there are about less then a 10th number of applicable RbxLua classes
This is sensible, however. I’d support this
Yeah, that really bugs me