I am proposing the addition of a new method that acts as an alternative to GetChildren with the ability to filter results based on their properties. A usage case would be finding all models in workspace with the name “Bob” as below:
local bobs = workspace:GetChildrenWithProperties({Name = “Bob”, ClassName = “Model”})
for i,v in next,bobs do
print(“found another bob”)
end
This would remove the need to do stuff like “if child.Name == ‘Bob’ and child:IsA(‘Model’)” which can at times add up to a long line of “if this and that and this and this and this” if you need to check multiple properties. I also expect that it would be handled outside of Lua like other ROBLOX methods resulting in potentially better performance than the alternative (though I could be wrong about that in which case ignore this bit).
A similar alternative to FindFirstChild could also be made, like how we currently have FindFirstChildOfClass.
function GetChildrenWithProperties( object, properties )
local children = {};
for _, obj in pairs( object:GetChildren() ) do
local conditionsMet = true;
for prop, val in pairs( properties ) do
local success, check = pcall( function()
return ( obj[ tostring( prop ) ] == val );
end );
if ( ( not success ) or ( not check ) ) then
conditionsMet = false;
break;
end
end
if ( conditionsMet ) then
table.insert( children, obj );
end
end
return children;
end
local children = GetChildrenWithProperties( workspace, { ClassName = "Part", Transparency = 0.5 } );
print( unpack( children ) );
DistanceFromCharacter was added way before ROBLOX grew to the size it is currently – not a good example. If it were suggested now, it wouldn’t be implemented.
Then it should be deprecated.
And that doesn’t really excuse very poor API decisions.
Which they have considered API additions to avoid bloat carefully for years as evident from my getproperties thread.
I really don’t think size means anything.
Has nothing to do with predicting the future. (Vec1-Vec2).magnitude existed before that API got added. They should of known it was bloat from the start.
Never claimed it was nor was I trying to imply such.
Its more like previous API methods set a precedent for how useful does an API method have to be before you can conclude whether its addition is justified or its useless bloat? And when you’re arguing bloat and implemented a method like that (I don’t see where ROBLOX being a sanbox game or UGC platform even matters in this case) it really doesn’t help the company and its staff when they make statements about bloat. Its kind of the idea of if you’re going to set a new standard or policy you have to fix whats already there if you want it to appear to have a lot of grounding.
Granted I know the team has priorities and often old stuff isn’t thought about.
Roblox isn’t going to go through and deal with past mistakes as a priority. There are a lot of other things they have to take care of first. If they have a new standard its best that they adhere to that new standard and worry about the old stuff later. Its like learning from past mistakes.
Things have to be considered before something is deprecated. What other API do they have to support the use case? What if something in that API breaks and lots of old games are using it, do they just stop caring because of a “deprecated” tag?
Its a lot more than slapping a [THIS IS DEPRECATED] tag on it.
Most of these were added as recently as July, this year. If we compare the options: One method to find child instances given a much more powerful filtering option, or a bloat of methods (OfClass = .ClassName, WhichIsA = :IsA), I do believe that we would save us a bloated API by having made this decision long ago.
Obviously, the existing methods cannot just be removed - and adding this one will only add more clutter. However, classifying this method as API bloat seems unreasonable compared to the abovementioned case.
We also use something similar for TweenService:Create, in terms of using a table with property-value pairs. If issues were to arise, it would affect both methods - and will already need to be dealt with, because TweenService:Create uses that setup.
A good concept to use when deciding if an API should be added or not is having the API start on minus 100 points. You then need to come up with sufficient reasons to offset this minus 100 negative. It is easy to think that adding an extra utility API here or there isn’t a problem because it has some value to a small number of people, but you really have to consider if it outweighs the negatives such as harder to understand API or the engineering time taken to implement it.
