So I just found out that the second parameter of Instance.new() is deprecated

BTW FIRST POST WOO (besides the intro)

Anyways, the proper practice for creating a new object is defining all of its properties before setting its parent (which in fact makes a big difference. I can post the thread if y’all like)

What if I want to alter an objects property after the parent has been set? Are there ways around this? Because obvs I can’t do that when the parent is nil.

ie.

local part = Instance.new(“Part”)
part.Anchored, part.Transparency = true, 1
part.Parent = workspace

for i = 1, 0, -.1 do wait()
part.Transparency = I
end;

–Would this still be considered good practice? I can’t think of any other way around this. Btw if someone would kindly teach me how to format my code in posts pls ty

3 Likes

That specific example is fine. The part needs to be rendered for the transparency to even show.

1 Like

It’s only more efficient to set the parameters before parenting the newly created instance than changing them after the parent of an instance was set. There’s no problem with altering the parameters later if you want something to change dynamically during the gameplay.

The exact reason this is deprecated is due to replication. If you parent an instance somewhere it will replicate, and then set properties what ends up happening replication-wise looks like this:

  • Send instance
  • Property 1 changed to…
  • Property 2 changed to…
  • Property 3 changed to…
  • Etc, etc

If you parent after setting properties replication simply looks like this:

  • Send instance

This, one, uses less network data, two, includes less packets to process, three, doesn’t need to dispatch events, four, doesn’t need to update visuals depending on the instance, and much more (some instances are actually more expensive than others due to extra processing they do).

I still use the second argument of Instance.new only when I know the instance isn’t going to replicate to the client. The last exception is when I don’t set any properties which is rare.

Example:

local folder = Instance.new("Folder")
folder.Name = "SomeFolder"
local boolValue = Instance.new("BoolValue", folder) -- Doesn't replicate because folder is parented to nil still
boolValue.Name = "SomeValue"
boolValue.Value = true
folder.Parent = workspace

Example two (Cameras don’t replicate children)

local holder = Instance.new("Camera", workspace) -- I don't set properties, and properties don't replicate, so I don't need to worry
local folder = Instance.new("Folder", holder) -- I did it because it rhymes... But actually I did this because, despite the camera being in the workspace, the folder won't replicate to the client
folder.Name = "Abc123" -- This is still not ideal as now extra events have to be dispatched for the name change, but honestly, it's not that big of a deal
12 Likes

There is a huge debate on wether it’s deprecated or it’s just bad practice, I’m on the bad practice side because from what I know there is no official resource saying that it’s deprecated.

As you said it’s bad because the Parent property is set before initializing properties, and that just means

local part = Instance.new("Part", workspace)
part.Transparency = 1
--is the same bad performance as 
local part = Instance.new("Part")
part.Parent = workspace
part.Transparency = 1

So it can’t really be considered deprecated in my opinion at least!

2 Likes

Cheers! Very informative.

The other replies were really helpful as well. Thank you

1 Like

The wiki page CrazyMan32 mentioned doesn’t seem to exist.
And the official Announcements post never mentionned the word “deprecated” it just says bad performance.

You can view the wiki page on archives, and CrazyMan32 is well known. The function usage that he was referring to (Instance.new with parent argument) is in fact deprecated, and has been for quite a while.

Edit: It is possible that it could have been “dedeprecated,” but the fact that it was marked as deprecated before, and now has a note alongside it shows it would be deprecated if it was not used as commonly. It’s sort of “half-deprecated” I suppose, but officially, it was, and probably still is marked as deprecated internally.

1 Like

I guess it’s not technically deprecated:

However, it’s bad practice to use it. I recommend reading through the “PSA” thread that @Hexcede shared and understanding why it’s bad practice. I never use it anymore.


The reason it’s not deprecated is unknown to me, but I can speculate: Deprecating a feature in the IT world usually happens when either a new feature is added that can replace the old one (e.g. DataStores replacing the Player DataPersistence API) or the old feature is no longer needed (e.g. Outlines on Roblox). In this case, setting the parent of an instance is a fundamental feature of Roblox’s engine.

The only reason using the second parameter of Instance.new is bad is because of when it sets the parent. The same problem would happen if you set the parent manually before editing the properties (see the thread I linked above). So the feature itself is not broken or in need of replacement; rather, it simply uses the API in an inefficient manner.

3 Likes