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

[Infocus]

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

[sjr04 (uep)]

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

[Kacper]

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.

[Hexcede]

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

[starmaq]

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!

[Hexcede]

@starmaq

There is a huge debate on wether it’s deprecated or it’s just bad practice

@Crazyman32

I was just looking at the Instance wiki page, and noticed that the method signature Instance.new(className, parent) is deprecated. Anyone know why this is, and how long it’s been like that?

At the very least, it has a strike through its name, which typically indicates deprecation, but there’s no explicit language otherwise.

(Standard Instance.new(className) does not have a strike through it)

Edit: I guess the paragraph after it describes why.

PSA: Don't use Instance.new() with parent argument

I’ve discovered a pretty bad performance issue in one of top games that has to do with Instance.new and wanted to write about this, since this is not obvious unless you know the system inside out. Tthere are several ways to create a ROBLOX object in Lua: local obj = Instance.new(‘type’); fill obj fields local obj = Instance.new(‘type’, parent); fill obj fields local obj = util.Create(‘type’, { field1 = value1, … }) If you care at all about performance, please only use the first option - I wi…

[Infocus]

Cheers! Very informative.

The other replies were really helpful as well. Thank you

[starmaq]

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.

[Hexcede]

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.

[sleitnick]

I guess it’s not technically deprecated:

Instance.new refers to parameter that doesn't exist and fails to mention deprecated parameter

I’ve updated the description of Instance.new to include the following performance warning: [image] It should be noted that a similar warning is given on the Instance.Parent property: [image] As @Legoracer has already pointed out, it isn’t technically deprecated. Such a designation has a specific tag in the API dump. The old wiki (which itself is deprecated, mind you) was also edited in October 2016 with the strikethrough, though no API happened to officially deprecate the second argument. …

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.