Super common problem in gui programming: You have a list that contains a mix of actual list contents (GuiObjects) and layout constraints. You need to clear the list to display new contents.
Current solution:
for _, obj in list:GetChildren() do
if not obj:IsA('GuiObject') then continue end
obj:Destroy()
end
What I want to do:
list:ClearAllChildrenWhichAreA('GuiObject')
Easier to read, easier to write, instantly cleans up any code that populates lists or grids.
Is there a particular motivation towards this being a native method instead of a utility function you have? We don’t love adding things like this (especially on Instance) without serious value.
I think it’s bad to require strong arguments for adding things to Instance. Roblox should make their core API as ergonomic as possible instead of relying on users to fill in the gaps. If you rely on users like this as a rule then you end up with friction across your entire developer ecosystem where people need to learn an entirely new API toolset to join a project. There’s obviously a desire for standards across the platform, which is why you see things like Fusion and Roact. New developers come into this and can’t figure out what they should be using or where they should be getting it from. Developers can’t be trusted to coalesce upon frameworks that are accessible, forward-looking, and rigorously tested (see: Rojo not working with packages for the fifth year in a row). The entire reasoning chain here needs to be reevaluated with the knowledge of what developers are actually currently doing and how it can be improved.
Pros of an instance method:
Cons of an instance method:
Pros of writing it yourself
Cons of writing it yourself:
This stuff all applies to instance methods in general
I often find myself writing out long-hand alternatives to functions like these which makes my code longer, takes more time, and overall slows my game development process. It’s annoying to type this out over and over again. I find a wide variety of use cases from gui to map systems of my game. By having built-in methods it will improve my development experience by making code more readable and understandable whilst avoiding unneccessary code lines.
There’s already the basic Instance:ClearAllChildren(), which I personally have never found a use case for because there’s always some kind of condition I need.
Personally, I feel that methods like Instance:ClearAllChildrenOfClass() and Instance:ClearAllChildrenWhichAreA() for clearing child objects of class and child objects of class with inheritance (respectively) would be really useful.
Useful for what actually concrete examples?
The bar for something being added on Instance is high, but if you can give a bunch of good examples you could get there.
ScrollingFrame/Frame which also contains formatting and appearance instances like UIListLayout, UIStroke, UIGridLayout, etc. For things like leaderboards and player lists where a sample frame is cloned and modified.ViewportFrame, clearing all LocalScripts from the character so they aren’t being run again.Instance:ClearAllChildrenOfClass().VehicleSeat instances or constraint instances depending on the player’s choice.These are just a few examples of where Instance:ClearAllChildrenOfClass() and Instance:ClearAllChildrenWhichAreA() would come in really helpful. I tried to pick examples which would be more relavant to a wider variety of games and therefore useful in more games.
Agreed. This is is an API I have found myself wanting a few times per month, for 10+ years now.
Specifically for the main reason in quoted reply:
I feel this can be pretty useful for clearing specific items when there are other existing items at play; However, I feel like each example - while similar - has its own use case for a specific purpose, where :ClearAllChildren() is for when you need to remove everything, while a for loop allows you to customize what specific condition should occur when it finds a specific object.
One example (which is the main reason people want it in the first place) would be when you have a hirearchy of disposable items of the same class, but you have objects that are essential for all the said disposable items. What it could do is only remove the disposable items when you specify their class, and only the essentials remain for later use of more disposable items.
Though, the alternative I can think of is CollectionService to identify and dispose of the disposable items:
for _,v in CollectionService:GetTagged("DisposableFrames") do
v:Destroy()
end
In my opinion, its cool, has its cases, and would be very convinient for said cases.
Maybe an argument can be incorporated into the already existing function for those cases, like:
I feel like the same could be said about stuff like :FindFirstChildOfClass() or :FindFirstChildWhichIsA().
for _,v in this:GetChildren() do
if not v:IsA(that) then continue end
return v
end
-- when you can just say this:
this:FindFirstChildOfClass(That)
Even :ClearAllChildren(),
for _,v in this:GetChildren() do
v:Destroy()
end
Another one being :WaitForChild(), where before 2013,
--// THEN
function waitForChild(parent, childName)
local child = parent:findFirstChild(childName)
if child then return child end
while true do
child = parent.ChildAdded:wait()
if child.Name==childName then return child end
end
end
local object = waitForChild(This, "That")
--// NOW
local object = This:WaitForChild("That") -- takes up a single line
-- very convinient and people take that for granted now
Very well-written; our studio personally uses a luau-defined version of such a method for clearing UI containers, without removing the aforementioned ‘appearance’ instances. ClearAllChildrenWhichAreA would be super helpful, however it is quite the word soup. Perhaps ClearChildrenOfType or ClearChildrenByClass could work, however Roblox makes a distinction between “IsA” and “Class”, where IsA matches sub-classes, while e.g. FindFirstChildOfClass matches the specific class. However, FindFirstAncestorWhichIsA does already exist, so perhaps this isn’t much of an issue in the first place.
Maybe it’d be easier to get something like this added? Would at least stop the endless “if instance isn’t instance I want” boilerplate spam.