Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancements to signal definition #24013

Closed
QbieShay opened this issue Nov 27, 2018 · 7 comments
Closed

Enhancements to signal definition #24013

QbieShay opened this issue Nov 27, 2018 · 7 comments

Comments

@QbieShay
Copy link
Contributor

Godot version:
custom 3.1 11d7738

Enhancement 1
It is currently possible to define a signal without specifying the signature of if (and by signature i mean the list of arguments)

signal some_signal
signal some_explicit_signal(param1, param2)

In my experience having an argument list for a signal makes the overall code more readable and less prone to errors.
I would also like to add that the signal is not fired properly if there is a mismatch with the arguments it is emitted with and the arguments that are expected by a function connected to it, but this is not reflected in the signal definition (no need to specify the number of parameters)

Enhancement 2

It is not possible to define types of the signal arguments, which would be nice for readability.

signal some_more_explicit_signal(param1: String, param2: Object) #<-- will not compile
@QbieShay
Copy link
Contributor Author

QbieShay commented Feb 5, 2019

@vnen

@vnen
Copy link
Member

vnen commented Feb 6, 2019

It is currently possible to define a signal without specifying the signature of if (and by signature i mean the list of arguments)

AFAIK you are always specifying the number of arguments, just that in the empty case the number is 0.

It is not possible to define types of the signal arguments, which would be nice for readability.

I've purposefully omitted for the sake of limiting the feature-set in this initial implementation. Adding types in signals means that there should type-checking somewhere, and I'm not sure how to deal with that yet. It's probably needed to do runtime-checks since it's not always possible to detect the functions connected to a signal.

I do plan to eventually tackle this though.

@QbieShay
Copy link
Contributor Author

QbieShay commented Feb 6, 2019

You can declare some_signal and then do emit_signal("some_signal", arg1, arg2) that will compile and work

@QbieShay QbieShay closed this as completed Feb 6, 2019
@QbieShay QbieShay reopened this Feb 6, 2019
@vnen
Copy link
Member

vnen commented Feb 6, 2019

Oh, this a problem with emit_signal() then.

@QbieShay
Copy link
Contributor Author

QbieShay commented Feb 6, 2019

@vnen I imagine this breaking tons of scripts if it gets fixed

@menip
Copy link
Contributor

menip commented May 30, 2019

So should be left for 4.0?

@Calinou
Copy link
Member

Calinou commented Sep 1, 2021

Closing in favor of godotengine/godot-proposals#2557, as feature proposals are now tracked on the Godot proposals repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants