FastSignal has moved to BindableEvents because of the issue Ukendio bringed up with the pairs issue and etc, which I’m currently to dumb to fix and don’t think I should be caring much about anyway since the speed advantages aren’t really significant to me or to really anyone. Yeah, it does mean that it’s slower, but it also means I got it to work with :ConnectParallel(), easiest thing with BindableEvents but yeah.
Meanwhile, Luau seems to get ready to be open-sourced, you might expect for some of the internal Signal code for Luau to be shown to the public with that.
Anyways I’m gonna go back to fixing some issues with my other projects.
This signal has a flaw which I would like to mention. This module doesn’t support multiple callback functions → My bad, I didn’t read the source code properly.
It would also be better to return the time the event yielded for with the result it self when using Wait, Bindable.Event:Wait doesn’t return the time it yielded the thread for.
function Signal:Wait()
if not self.Active then return end;
local before = os.clock()
local result = -- result
self._event:Wait()
return result, os.clock() - before
end
I know but… um no. That’s just no? I got recommended to not do so, :Wait() is just supposed to return whatever you fired the signal with, this is talked about here even:
So, not really. If I wanted to, maybe, this was the case when I didn’t know, but if I wanna have a really similar to original Signal API, that’s just the way to go. I belive I also use :Wait() internally in my projects with the data it returns so. Yeah…
Does it not? Are you sure about that? self._event is just BindableEvent.Event, it’s only there so I don’t have to index as much. Indexing less is faster.
About the not connecting the function directly, that’s essentially what the Quenty’s signal API does, because I guess BindableEvents shallow copy stuff? Anyways, sad.
It should be slightly but not noticeably faster than the Quenty’s one because i’m just using table.pack() and table.unpack() which handle the argument count ‘automatically’ and should be faster, and also because I have the _event thing, but that doesn’t matter much.
Event oriented programming i dont think that’s what it’s called but i don’t remember
Does it not? Are you sure about that? self._event is just BindableEvent.Event , it’s only there so I don’t have to index as much. Indexing less is faster. About the not connecting the function directly, that’s essentially what the Quenty’s signal API does, because I guess BindableEvents shallow copy stuff? Anyways, sad. It should be slightly but not noticeably faster than the Quenty’s one because i’m just using table.pack() and table.unpack() which handle the argument count ‘automatically’ and should be faster, and also because I have the _event thing, but that doesn’t matter much.
My bad, I didn’t notice that you were using a bindable event.
So, not really. If I wanted to, maybe, this was the case when I didn’t know, but if I wanna have a really similar to original Signal API, that’s just the way to go. I belive I also use :Wait() internally in my projects with the data it returns so. Yeah…
No, you most likely confused my point. What I meant was to return both the time it yielded for and the result it self. Please read my points a bit more carefully.
It should be slightly but not noticeably faster than the Quenty’s one because i’m just using table.pack() and table.unpack() which handle the argument count ‘automatically’ and should be faster, and also because I have the _event thing, but that doesn’t matter much.
Well if it doesn’t matter much, which it doesn’t, what’s the point?
Event oriented programming i dont think that’s what it’s called but i don’t remember
I ended up thinking Bindables only shallow copied stuff. They DEEPcopy. That’s not the case, so I’ll fix that by using a method which I’m gonna try out and I’ll talk about later.
Quenty’s has a problem if you :Fire() it inside a listener. I plan on ‘fixing’ that.
It’s probably about time Roblox gives us a Signal constructor.
If you’re using coroutines, you need to have super complex systems so that you don’t have any issue with the stuff Ukendio talked about.
If you’re using bindableevents, the problem is the deepcopying, so you need to have a reference to whatever you’re firing.
Essentially we use BindableEvents to just handle the firing and connecting, and the arguments we have to handle ourselves atm.
So there’s problems everywhere.
With the fix enabled, it is slower, but only noticeable if you’re firing a lot and benchmarking really, you should be fine. And it doesn’t have the fireing inside a listener issue.
Edit: removed fast from fast signal cry it’s still pretty versatile though.
, easiest thing with BindableEvents but yeah.
