glSignal | Utility Focused Signal Library

Resources Community Resources
, , ,
1
Utility focused signal library. Inspired by signal+ and lots of other signal libraries. Contains 4 unique methods with useful behavior that I've found myself wanting in various signal libraries.

module
source

methods 
--[[
glSignal
	new<T...>() -> (glSignal<T...>)
		Disconnect all connections. Clears the linked list and relevent items get GC'd.
			disconnectAll: (signal: glSignal<T...>) -> (),

		Bind a function to the signal. This is the default connection which all other connection types inherit from.
			connect: (signal: glSignal<T...>, callback: (T...) -> ()) -> (glConnection<T...>),
			
		Bind a function to the signal, after one usage it will be automatically disconnected and gc'd.
			once: (signal: glSignal<T...>, callback: (T...) -> ()) -> (glConnection<T...>),
		
		Bind a function to the signal, after <amount: number> uses, it will automatically disconnect.
			limit: (signal: glSignal<T...>, amount: number, callback: (T...) -> ()) -> (glConnection<T...>),
			
		Bind a function to the signal, after each signal fire <evaluationFunction: () -> (boolean)> will be executed. 
		If it returns true it will automatically disconnect.
			each: (signal: glSignal<T...>, evaluationFunction: () -> (boolean), callback: (T...) -> ()) -> (glConnection<T...>),
			
		Bind a function to the signal, after <disconnectAfterSeconds: number> seconds, it will automatically disconnect.
			after: (signal: glSignal<T...>, disconnectAfterSeconds: number, callback: (T...) -> ()) -> (glConnection<T...>),
			
		Yields execution until the signal is fired. Returns T... after the signal has been fired.
			wait: (signal: glSignal<T...>) -> (T...),
			
		Yields execution until the signal has been fired or <timeOut: number> has elapsed. If it times out, nil will be returned in place of T...
			waitUntil: (signal: glSignal<T...>, timeOut: number) -> (T...),
			
		Fires the signal with T... as arguments. 
			fire: (signal: glSignal<T...>, T...) -> (),
			
		Destroys the signal and connections.
			destroy: (signal: glSignal<T...>) -> ()
	
glConnection
	connect: (signal: glSignal<T...>, callback: (T...) -> ()) -> (glConnection<T...>),
		Disconnects the connection.
			disconnect: (connection: glConnection<T...>) -> ()
		Whether or not the signal is currently connected.
			connected: boolean,
		The amount of times the signal has been called.
			calls: number,

If you have questions or issues message @sodere on discord. I’ll also likely reply on here for a while.

3 Likes
2

An another one not needed Signal module that uses LinkedList without any reason to do so. on top of that, there’s a lot of potential memory leaks here.

image
image521×206 4.2 KB

image
image521×257 5.38 KB

image
image
image581×104 2.96 KB

If it supposed to be beginner friendly, then you should be wary that there are functions like task.wait, which yield thread and they don’t make thread objects garbage collectable. Also you don’t reuse threads, which leads to code inefficient runtime. I would’ve made an expansion to like fixed arguments (all the arguments after the callback given in Connect will be stored and given on this connection event fire).

The amount of indexations and not very needed functionality is also huge. But I guess you need it (functionality) somewhere, so alright, but you better decrease the amount of indexations.

The idea is good, the realization is meh.

Also I suppose you’re looking after YarikSuperpro OOP method, which is also gives a huge memory leak due to it’s being a dictionary.

3

I’ll be implimenting a better approach to the :wait() and thread usage as that’s an oversight on my part, however I don’t really understand the sentiment of dicts being a memory leak. Once they’ve gone out of scope they should be treated the same as any other object. If you have a benchmark or source on that I’d like to see it.

4

Each time of constructor call you’re creating a new string index inside of a table which takes 1 byte per character instead of just giving a link to a table with already created dictionary stored functions, that is what I meant by memory leak. Although I might’ve said it wrongly, sorry if it so.