In the same fashion that all Part objects inherit from the super-class BasePart, all folder/container objects should have a common super-class that we can identify them with for instance methods such as ::IsA and ::FindFirstChildWhichIsA. This will improve efficiency in code when one needs to find all container objects in a directory but don’t want to make 2 or more ::IsA calls.
You might want to list some specific use cases where you’ve needed this – can’t say I’ve ever needed this before. I think the only real thing these classes have in common is that their icons are similar. If they have a superclass, then Model should be involved too, but Model has specific API implications that these other objects don’t have, so it would be very quirky for specifically these objects to have a common superclass. (“some containers have a superclass, but only these specific containers”…)
I stated my use-case in my original post. This is an issue I’ve ran into more than once because I use a lot of both Folders and Configurations in my work and a common identifier would provide a more streamlined experience in writing code that uses these objects when parented under the same instance.
when one needs to find all container objects in a directory but don’t want to make 2 or more ::IsA calls.
If we take a look at the devhub page for Configuration, it states that
And if we take a look at the devhub page for Folder, it states
Folder | Roblox Creator Documentation
A simple container used to hold and organize Roblox objects. Unlike other container classes like Model , it offers no additional functionality.
The common denominator here is that these objects serve no purpose other than for organization of other instances, thus they have no methods or properties inherited from anything except the Instance superclass. The Model class would not be included here because models are used to perform specific actions on groups of BaseParts such as controlling their world position/orientation - this is why it inherits the superclass PVInstance.
A middle ground here would to possibly have Configuration inherit from the Folder class. Obviously it would inherit no specific members but it would allow a more organized class structure. The downside of this is that it could cause false positives in old code that tries to detect Folders with IsA methods and it picks up Configurations as well in doing so.
As for Backpack and StarterGear, I’m still scratching my head to the thought of these being creatable instances. What I can tell you however is that they provide no functionality outside of Roblox’s internal engine, and should probably not even be creatable for this reason.
Why not use Folders exclusively? This would circumvent the need for having these objects have a superclass.
If the reason happens to be “because the icons are different so it helps me traverse my game tree visually”, perhaps the actual issue here is that you don’t have a good way to distinguish different kinds of containers while also being easy to traverse. And that can be solved in several ways, one of them being having a superclass of these objects, but we should focus on problems rather than proposed solutions, which is why I poked about adding your actual use cases so that engineers/product people at Roblox can figure out the best solution.
At the risk of sounding pedantic, I’ll say that I use Configurations for their stated purpose (found on devhub) and for no other reason(s)
The Configuration object is a container object that is designed to hold value objects to make values used in Tool s or any model using Script s more accessible.
In my eyes asking “why not use folders exclusively?” is the same as “why aren’t configurations deprecated?”. I could easily use a Folder named “Configuration”, yes, but when I go to insert a new object in the explorer I’m presented with the Configuration object which already has the name filled in for me and serves the same exact purpose. The only difference being that one object is older than the other in terms of how long it’s been in the API.
If Roblox insists on creating dupes of Instances without deprecating one or the other, they should at least allow us to easily identify them as the same thing. A great example of this is ScreenGui vs GuiMain. When Roblox introduced the ScreenGui object, they deprecated GuiMain shortly after and now GuiMain:IsA('ScreenGui') returns true because they’re the same thing & it makes sense to be able to identify a legacy GuiMain object as a ScreenGui.
If Roblox decides to deprecate the Configuration object, I’ll no longer use it and my problem will ultimately be solved - due to the fact that deprecated objects should not be used in new work.