Scripting Helpers is winding down operations and is now read-only. More info→
Log in to vote
0
(SOLVED) Awaiting signals: coroutines or bindables?
hello everybody,
recently I attempted to create my own signal class. I noticed that other users have had two different approaches for creating Event:Wait(); either they create a bindable and fire it along with the signal like so
01 | function Signal.new() |
02 | local self = setmetatable({}, Signal) |
03 | self._Yield = Instance.new(“BindableEvent”, script) |
04 | return self |
05 | end |
06 |
07 | function Signal:Fire(...) |
08 | self._Yield:Fire() |
09 | -- run listeners |
10 | end |
11 |
12 | function Signal:Wait() |
13 | self._Yield:Wait() |
14 | end |
or they use coroutine.yield on the current thread and create a listener to resume when the signal fires
01 | -- same things without the bindable |
02 |
03 | function Signal:Wait() |
04 | local thread = coroutine.running() |
05 | local connection = Connection.new(self) -- object used for indexing |
06 | local function resume() |
07 | connection:Disconnect() |
08 | coroutine.resume(thread) |
09 | end |
10 | self[connection] = resume |
11 | return coroutine.yield() |
12 | end |
I went with coroutines because it was based on pure lua. I haven’t really found anything comparing the two. is one really better practice than the other?
thanks.
1
I recommend coroutine.yield since if you say you create your own class then it just fits more rather than creating class that calls methods of existing class. Roblox :Wait() calls the same coroutine.yield, however, Roblox somehow manages to make it quite performance inefficient, not like it's that noticeable but making your class is still better since you have 100% control over it. imKirda 4491 — 4y
0
interesting, I did not know that they used the exact same procedure; both options seemed a bit hacky to me, haha. I agree that there is no point in creating an instance to carry out the same effect. thanks. Speedmask 661 — 4y