Implement a remove_user_signal method

[DeletedBunny]

I find it odd that there is a add_user_signal method on Object but there is no way to remove it. I see that that a signal is erased from the internal signal_map on Object, only on the destructor and on disconnect if it's not a user signal.

I suggest either to implement a method remove_user_signal or remove user signals on the disconnect method (however this would have impact on already existing applications).

[dalexeev]

I think that there is no need for this, removing signals is like removing methods. Frequent addition/deletion/connection/disconnection of signals should be avoided. If you have many similar signals, then it's better to use one signal with different arguments.

I don't remember using add_user_signal at least once (I always use the signal keyword), although I use set, get and call sometimes.

[DeletedBunny]

I found it useful to use add_user_signal for creating an event aggregator. I thought it might be useful when you need to unsubscribe from an event aggregator while the object is still alive. I first tried using the signal keyword to make an array of signals but that did not work.

Maybe there is a better way to make event aggregators in godot that I do not know about but being able to add a signal you should have its equivalent to remove it or at least get a reference to the map to remove it yourself.

[theraot]

It is a very rare use case.

Frequent connection and disconnection of signals is fine. Evidence of this is the fact there is a CONNECTION_ONESHOT flag.

However, it is better when the object that uses the signal is responsible for said connections and disconnections (or the connection is there for the lifetime of the objects). If there is one script connecting and disconnecting and a different script receiving the signals, it makes it harder to reason about the code. To be clear: it is not a no-no, but do it consciously.

And that is the issue with remove_user_signal: What happens to the connections? We would have to remove the connections when the signal is removed. But logic that depends on the connection could not work correctly (some process stuck never completed but not aborted either because the signal was never emitted).

---

If disconnect removes the connection when there are none left - which is the other alternative you suggest - the code that connects to it does not know if it has been removed. Thus, you must always check if the signal exists, and create it if it does not, before attempting to connect to it.

Perhaps this fine with you, if this is how you are already using user signals. For example, you have generic mechanism that might emit a user signal if it exists, and then it is responsibility of the code that connects to create the user signals.

However, that is not the only possible pattern. A user signal not existing can also be meaningful. Because it needs a mechanism for emitting it, and there is no point on creating user signals if you can't emit them… So there is no point in creating signals to connect to them if said mechanism that would emit them is not in place... Which would be the case if the mechanism is not generic for the possible user signals.

---

To be fair, even when connections are there for the lifetime of objects we can run into problems. For example, when an object that yields is freed, when the signal is emitted Godot will try to resume execution, but can't. Thus, it is better when the object that yields is also responsible for its own lifetime. We can work around that, by the way: if we used connections with CONNECTION_ONESHOT flag instead of using yield (it takes some refactoring), when the object is freed its connections are removed and thus Godot won't try to execute them when the signal is emitted.

---

By the way, if you have many signal - as @dalexeev mentions - you can make a single one and distinguish by arguments. However, you need to think about how it will be used. Because merging different signals might mean that objects will get unnecessary notifications. For example, SceneTree has a node_added that will report when any Node is added anywhere on the scene tree, which makes it virtually unusable… Most of the time we want notifications about direct children added (to the point that people used to shadow add_child with their own method - to be clear add_child is not virtual), and we are getting much more useful child_entered_tree and child_exiting_tree in Godot 4.

In fact, that is one way you could create and remove signals: create and remove objects that have signals. And you can have arrays or dictionaries of said objects. But before you go on doing that, I would challenge the idea that you need this. As I said at the start, it is a very rare use case.

Do you actually need to create signals at runtime, or is it just a convenience to not declare signals? Because if it is a convenience for not declaring signals I have an alternative: resource based communication. You can define signals on a custom resource via an script. You can create resource files of the custom resource type on the file system. And everywhere you preload one of those resource files (or if you set it on an exported var from the inspector), you get the same object. And multiple places with the same object can communicate with each other via its signals. Thus, instead of going to a central script to declare more signals as you need them, you can create more resource files as you need them and store them with the scene that use them.

[RadiantUwU]

Closed by godotengine/godot#90674