[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.
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.
local spawnWithArgs do
local event = Instance.new'BindableEvent'
function spawnWithArgs(f, ...)
event:Fire(f, ...)
end
event.Event:connect(function (f, ...)
f(...)
end)
end
[quote]
local spawnWithArgs do
local event = Instance.new'BindableEvent'
function spawnWithArgs(f, ...)
event:Fire(f, ...)
end
event.Event:connect(function (f, ...)
f(...)
end)
end
:woohoo: [/quote]
local t = {true, nil, false, nil} print(unpack(t))
true
[/code] [/quote]
local function pack(...)
return {n = select('#', ...), ...}
end
t = pack(true, nil, false, nil)
print(unpack(t, 1, t.n)) --> true, nil, false, nil
Lua 5.2 adds pack to the standard library, which does exactly this. Very handy.
[quote] I don’t ever use coroutines or spawn or delay, so I don’t exactly know how they work or what they’re used for. But might this work?
local function spawnJump(...)
coroutine.wrap(jump)(...)
end [/quote]
Almost, but not quite the same. The coroutine will begin running immediately and allow the calling thread to continue only after it dies or yields. With spawn(), the new thread is queued without actually resuming it first. For example:
print('A')
coroutine.wrap(function() print('B') end)()
print('C')
--> A
--> B
--> C
print('A')
spawn(function() print('B') end)
print('C')
--> A
--> C
--> B
[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.[/quote]
Indeed, but what if it was instead a function that takes a variable number of arguments? Then the proposed change shows again how it is useful.
The solutions woot3 and LuaWeaver suggest are somewhat complicated for something that should be so simple. My argument for adding this is that all the Lua functions (except xpcall?) that take as an argument a function that they run in some way support passing arguments to that function: pcall, coroutine.resume, …
I think there would be no question that the [tt]spawn[/tt] function should support this if it did not already pass two arguments to the function. That it does means it’s impossible to use other functions directly if they aren’t meant to be called only by [tt]spawn[/tt].