Solving the problem of forward compatibility with child indexing

Feature Requests Engine Features
#1

Recently there have been cases of code breaking due to new property names overshadowing child indexing.

Some examples of this include:

  • TextLabel.Content overshadowing children named Content if accessed through indexing
  • BasePart.BodyAngularVelocity overshadowing any child object with that name, which would be likely for any instance of the BodyAngularVelocity class.
  • The internal Instance.Tags property briefly overshadowed children named Tags until a change was made to the Lua bridge to ignore indexing non-scriptable properties (this happened a few years ago).

It seems unlikely that this practice will stop anytime soon. Even I use it sometimes because FindFirstChild and WaitForChild are quite verbose when used in bulk.

Going forward, I think all new properties that are added to existing developer accessed objects should have a special bit-flag set in their internal attributes which forces child indexing to take precedence over property indexing in the Lua bridge.

Using this flag would print a warning to the output whenever this behavior goes into effect (i.e. Someone tries to access a child whose name is the name of a new property). It could then be logged to analytics, and if it’s a widespread problem, a proper mitigation can be initiated.

Once the usage has cleared up sufficiently, then the flag can be removed from the property. If the problem will likely persist forever then the flag can just be left on.

34 Likes
#2

Child first, property second should’ve been the default behaviour in my opinion, even though it is bad practice I’m certain that there are some games rely on this behaviour today so that boat sailed long ago. I think these property names should be added anyways and the behaviour be kept the same and instead, we should get a dedicated topic in devforum with proper structure** where a developer can find whatever changes that were made with ease, release notes cannot serve this purpose, they are not warnings.

These warnings should include all of the potential changes that might break any game. Even if it’s something minor, it should be there. And they should be as brief as possible telling just what and how something might break.

** Announcements in the announcements category MUST have a proper structure. I must be able to get the relevant information about an update without having to read some cringy post that tries too hard to be funny, wasting all of the developers’ times. These kinds of posts in announcement category are unprofessional and counter-productive. Will make a meta thread about this.

4 Likes
#3

I seriously need this.

As a Roblox developer, it is too hard to write forward-compatible code without repeating myself all the time. As pointed out, excessive use of :FindFirstChild/:WaitForChild can make code seem extra verbose. I’m constantly using :FindFirstChild to get children I know can be there, and checking if the child exists since it feels wrong to index without verifying it exists, since that is how it was meant to be used.

local child = parent:FindFirstChild(child_name)

if child then
    local descendant = child:FindFirstChild(descendant_name)

    if descendant then
        etc()
    end
end

Most of it is really unnecessary.

I personally would propose something like Instance:GetChild(child_name: string), which works exactly like indexing for children. It would throw an exception if a child with that name doesn’t exist.

2 Likes