If I have a container with a bunch of GUI buttons, and an UIGridLayout, I might want to clear it fully, except for the UIGridLayout.
Currently, I’d need to run over all child instances of the container and remove each manually. With this feature, I could simply call
frame:ClearAllChildren("ImageButton")
and the Frame would be empty, except for the UIGridLayout.
As compared to this:
for _, item in next, frame:GetChildren() do
if item:IsA("ImageButton") then
item:Destroy()
end
end
My reasoning for clearing the container, is so that I can fill it up with new items when the user swaps pages that are dynamic, such as showing owned in-game items.
Easier to do this in Lua. A simple and robust API wins over the kitchen-sink approach.
local ClearSomeChildren do
local function CheckProp(obj, prop, val)
return obj[prop] == val
end
function ClearSomeChildren(obj, filter)
for _, child in next, obj:GetChildren() do
for prop, val in next, filter do
local s, r = pcall(CheckProp, child, prop, val)
if s and r then
child:Destroy()
break
end
end
end
end
end
While it certainly gives room for more control, most of the cases I’ll just want to write something simple without needing to write it all from scratch - given your example, the same can be done with @woot3’s suggestion, which in many cases would suffice to what people may want to do when using ClearAllChildren and similar other API methods.
That’s what code reuse is for :P Adding features just because of this just leads to API bloat.
Clearing children by ClassName is pretty specific, so I can’t imagine many use cases for it. In your case, a more appropriate solution may be to just keep track of the ImageButtons in a table, loop through that, and delete every item in it.
On the other hand, you and woot3 mention the need to filter multiple methods like this – that’s broad enough to be a feature. Can you provide some examples? Methods it’d be used for, what filters you’d use, and why you’d be using them.