function create(name, parent)
return function(props)
local new = Instance.new(name)
for i, v in next, props do
if type(i) == 'number' then
v.Parent = new
else
new[i] = v
end
end
new.Parent = new.Parent or parent
return new
end
end
What we really need is just for Instance.new to be able to optionally take a table as its second parameter. Both of you are interns, so hopefully you can convince the staff to do something about this. I end up using the same Instance Module over and over which is essentially what Merely requested (If the second parameter is an object it uses the normal Instance.new function, but if it’s a table it uses a custom function similar to the one you posted) and I just set Instance equal to the model.
Frankly, the syntax is ridiculous. It compiles a function which is also ridiculous, and it returns a function which is also, as I’ve been saying, ridiculous.
Yeah I write this far too often. The default studs and inlet are annoying as well, but changing that could break code that relies on it. Don’t hate people who take it for granted either, you wouldn’t like it if one day LeftSurface was changed to “Weld” as a default.
I feel like if this was to be added, functionality would be great. As in multiple parameters.
Also what are you talking about. Even if Instance.new’s second parameter was overloaded with a table you could still refrain from using parentheses.
[spoiler][code]
local oldInstance = Instance
Instance = {new = function(name, parent)
return function(props)
local new = oldInstance.new(name)
for i, v in next, props do
if type(i) == ‘number’ then
v.Parent = new
else
new[i] = v
end
end
new.Parent = new.Parent or parent
return new
end
end}
[quote] Also what are you talking about. Even if Instance.new’s second parameter was overloaded with a table you could still refrain from using parentheses.
[spoiler][code]
local oldInstance = Instance
Instance = {new = function(name, parent)
return function(props)
local new = oldInstance.new(name)
for i, v in next, props do
if type(i) == ‘number’ then
v.Parent = new
else
new[i] = v
end
end
new.Parent = new.Parent or parent
return new
end
end}
Your example is two function calls, not one. So if it were added then everyone who called Instance.new"Part" would suddenly be receiving a function instead of a part. Your example is basically the same as mine but with a different name.
In the past we’ve had RbxUtility break + you still have to put that line at the top of every script you want to use it in which is no different than using AHK to spy on Studio and replace “require(instance)” with “require(182880820)”. Overloading Instance.new() will make it easier and cleaner to use than RbxUtility.
Whether you noticed it or not I can guarantee 100% that RbxUtility was broken in 2014. I vividly remember looking at a friend’s model and finding out the reason it wasn’t working was because RbxUtility was broken. This wasn’t something caused by a bad studio installation either – it was broken in-game.
This has been discussed to death. Key/value tables don’t work because you can’t have nil values and you can’t set properties in a determinable order. These alone prevent it from being helpful.
Setting each property individually seems so long and tedious because you keep thinking about how you can avoid doing it. In reality it’s so inconsequential that thinking about it is a waste of time. You just get it over with and move on.
“you can’t set properties in a determinable order.”
There are only a few cases where the order matters. The only ones that I can think of are FormFactor and Shape needing to be set before size, but ROBLOX can determine that behind the scenes and set them in the correct order. That isn’t an appropriate reason to trash the feature request – it’s not a problem at all.
“because you can’t have nil values”
All Object values default to nil. It doesn’t matter if you can’t set it to nil from Instance.new – it’s already nil to begin with.
[quote] “you can’t set properties in a determinable order.”
There are only a few cases where the order matters. The only ones that I can think of are FormFactor and Shape needing to be set before size, but ROBLOX can determine that behind the scenes and set them in the correct order. That isn’t an appropriate reason to trash the feature request – it’s not a problem at all. [/quote]
Shape, FormFactor, Name, Parent, Position, CFrame, Surfaces and Value are properties (also some methods) I’ve set/used in different orders to achieve different behaviors. I dont think generalizing the set order behind the scenes is a very friendly solution if I have to go back and edit properties again to get my desired behavior. It defeats the purpose of an ease of use function IMO if I can’t get the circumstantial behavior I want easier than if I just typed it out as I do now.
I can defiantly see the appeal, especially for smaller objects. But anything that requires me to set lots of properties, and set them in a certain order isn’t going to work well for me if I can’t guarantee my behavior. If the entire concept behind the addition is to make setting lots of things easier, than it still does it’s job but fails me where I need it. In that case it’s easier for me to just type out the sets manually, again making the feature useless to me.
“Name, Parent, Position, CFrame, Surfaces, and Value”
What? None of those are affected by the order you set them in. None of them can be set to nil either. I don’t see the point you’re trying to make.
[quote] “Name, Parent, Position, CFrame, Surfaces, and Value”
What? None of those are affected by the order you set them in. None of them can be set to nil either. I don’t see the point you’re trying to make. [/quote]
I’ve had instances here setting the parent before the name has caught a few things up, same with value. It’ rare but it does happen, and I always set parent last because of it. I’ve had CFrame and Position behave different if a part is anchored after CFrame or Position is set, and I’ve found when dealing with physics objects setting surfaces before/after other property/method sets/uses will guarantee things work as apposed to them working most of the time.
They’re entirely circumstantial reasons, but that doesn’t mean they should be dismissed because they have a small chance to occur. They are all problems that can be worked around, but if I’m having to do a work around for something I could have solved by just settings things in the right order in the first place then there is something really wrong with how I’m making the object.
Theres always the option of running Instance in your own environment
local api={};
api.Instance{};
api.Instance.new=function(s)local obj=Instance.new(s)return function(t)for i,v in pairs(t)do obj[i]=v; end end end
local Run=function()Instance.new'Part'{Parent=workspace}end
setfenv(Run,api)
Run()
