Did you try actually using the [tt]…[/tt] in the inner (spawned) function? Because I tried and that’s what happens when you do.
(directly, doing something like
function spawnWithArgs(...)
local a, b = ...
spawn(function ()
use(a,b)
end)
endis fine)
Now that’s weird, wonder why it errors… as a workaround, if his method were wanting to be used, you can just pack then unpack them, I tested pack/unpack, and it worked.
Regardless, I’m sure roblox could make this feature, all I want is an efficient and convenient way to use spawn() with arguments, I don’t want to have to make a wrapper for spawn, I just want spawn to natively work in a logical way
Anaminus explained why passing spawn’s additional arguments to the function wouldn’t avoid the necessity of using anonymous functions. Here’s how it looks right now:
spawn(function()
Jump(0.5)
end)And here’s how your code would look with your proposed change:
spawn(function(_, _, height)
Jump(height)
end, 0.5)No matter what, it will still be necessary to create an anonymous function. At minimum it would be necessary to create a spawnWithArgs function.
Are you sure anonymous functions are a bottleneck for your code? Have you done any benchmarking?
[quote] Anaminus explained why passing spawn’s additional arguments to the function wouldn’t avoid the necessity of using anonymous functions. Here’s how it looks right now:
spawn(function()
Jump(0.5)
end)And here’s how your code would look with your proposed change:
spawn(function(_, _, height)
Jump(height)
end, 0.5)No matter what, it will still be necessary to create an anonymous function. At minimum it would be necessary to create a spawnWithArgs function.
Are you sure anonymous functions are a bottleneck for your code? Have you done any benchmarking? [/quote]
Wait, Spawn passes arguments to the function passed to it? I thought it just returned those two times, what does it pass?
And no, with my proposed edit, it should be something like spawn(Jump,0.5), since 0.5 is being passed within the tuple argument ‘…’ which spawn then turns around and passes to the callback (in this case Jump) when it’s called in a new thread… I feel I’m somehow being misunderstood, I want spawns code to look like the first example in my post, could you give me the roblox source? I could easily write the edit for you, and explain why it would work if you want, then we both know we’re on the same page at least.
Spawn() doesn’t return anything.
The problem is Jump would get passed the two things normally passed by spawn() as well, so you’d have to filter them out…with a function.
Yes, spawn calls the function with two arguments: the first being the amount of time which elapsed from when spawn was called to when the function was invoked, and the second being equivalent to elapsedTime() or roughly how long the engine has been running.
To verify this, paste this into studio’s command bar:
spawn(print)
--> 0.0079617658390703 451.55683163643Ahh, I get it now, read the wiki wrong,does anyone actually use the parameters? If so, could a new function like thread() be made, where you don’t have to use an anonymous function?
It’s certainly possible, but are there any performance reasons for creating such a function?
If you post some of your code which spawns anonymous functions, we may be able to suggest ways in which it could be rewritten to avoid using anonymous functions.
It’s not a major performance concern unless it’s on a renderstepped loop, but mainly I can write to avoid it
I just dislike the though of things being inefficient, and of there being a useless function created to be a middle-man, I’m very style oriented in my scripting.
[quote] It’s not a major performance concern unless it’s on a renderstepped loop, but mainly I can write to avoid it
I just dislike the though of things being inefficient, and of there being a useless function created to be a middle-man, I’m very style oriented in my scripting. [/quote]
Now is great a time as any to get over it. You don’t think about optimization until you’re writing benchmarks, and you don’t think about writing benchmarks until most of your codebase is actually finished.
[quote] It’s not a major performance concern unless it’s on a renderstepped loop, but mainly I can write to avoid it
I just dislike the though of things being inefficient, and of there being a useless function created to be a middle-man, I’m very style oriented in my scripting. [/quote]
Now is great a time as any to get over it. You don’t think about optimization until you’re writing benchmarks, and you don’t think about writing benchmarks until most of your codebase is actually finished.[/quote]
There is nothing to get over. I know how to properly program, I am not new to programming. Instead I am of the camp of ‘write it right the first time’ optimizing later is for people who write messy and slow code.
[quote]
23:29:21.008 - Error in script: cannot use '...' outside a vararg function near '...'You can’t use [tt]…[/tt] as an upvalue. [/quote]
Sure, but the implementation of the [tt]spawn[/tt] function is not in Lua and would be able to access the list of arguments after storing it in a variable (which is necessary anyway).
Premature optimization is the root of all evil, but that doesn’t mean extending the [tt]spawn[/tt] function to accept arguments cannot be a good idea for other reasons.
For example, if we take the code Seranok gave above but decide that instead of calling the [tt]Jump[/tt] function once we want to call it multiple times, with different values, then the proposed change becomes useful.
spawn(function()
Jump(0.5)
end)
spawn(function()
Jump(0.6)
end)
spawn(function()
Jump(0.7)
end)
spawn(function()
Jump(0.8)
end)The above can become what follows:
local function Jump_(_, _, height)
Jump(height)
end
spawn(Jump, 0.5)
spawn(Jump, 0.6)
spawn(Jump, 0.7)
spawn(Jump, 0.8)There’s no reason the function needs to be anonymous. In this case, the second option is clearly better, and also happens to create less function closures. Function closures are expensive, but here that’s insignificant: what makes the second piece of code significantly better is not that it can run faster, but that it is a more elegant solution to the problem.
[quote] It’s not a major performance concern unless it’s on a renderstepped loop, but mainly I can write to avoid it
I just dislike the though of things being inefficient, and of there being a useless function created to be a middle-man, I’m very style oriented in my scripting. [/quote]
Let’s forget the obvious, and talk about the idea of using spawn() in RenderStepped. If you intend to spawn a new coroutine, that the task scheduler runs on the next tick, every tick… Worrying about the inefficiency of an anonymous function is the least of your problems.
local function spawnJump(n)
spawn(function() Jump(n) end)
end
spawnJump(0.5)
spawnJump(0.6)
spawnJump(0.7)
spawnJump(0.8)There. Readability improvement with zero api changes.
[quote] [code]
local function spawnJump(…)
spawn(function() Jump(…) end)
end
spawnJump(0.5)
spawnJump(0.6)
spawnJump(0.7)
spawnJump(0.8)
[/code]
There. Readability improvement with zero api changes. [/quote]
Won’t work.
You can’t access varargs as upvalues
[quote]
You can’t access varargs as upvalues [/quote]
Aren’t I stupid.
Oh well, you don’t need the vararg in this case because we know Jump takes one argument.
What if you don’t need to start a new thread every time that Jump is called? I commonly create threads on the calling side because I have connections as well as the main thread call the same function, and since the connections don’t block the main thread, there’s no reason to create another thread for them.
[quote] [code]
local function spawnJump(…)
spawn(function() Jump(…) end)
end
spawnJump(0.5)
spawnJump(0.6)
spawnJump(0.7)
spawnJump(0.8)
[/code]
There. Readability improvement with zero api changes. [/quote]
Won’t work.
You can’t access varargs as upvalues[/quote]
function spawnJump(...)
local args = {...}
spawn(function() jump(unpack(args)) end)
end?
pack/unpack is an even worse performance hit, why can’t we have both style and performance?