-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Add @connect(object.signal)
method targeted annotation
#2946
Comments
For a reference, when I suggested this in the original annotations proposal, people reacted very well: #828 (comment) |
@connect(object.signal)
method targeted annotation.
So, @pycbouh suggested |
@MaaaxiKing I suggested it this way because signals were only accessible as strings back then. Now that signals are first-class properties, |
Yeah, sorry, I skimmed through that thread but somehow missed your and the other person's suggestions. I was actually genuinely surprised this was not one of the first things implemented with annotations since it looks like a very natural place for them to be used at |
@connect(object.signal)
method targeted annotation.@connect(object.signal)
method targeted annotation
And could we be passing extra arguments? Like we currently have bind arguments. |
Sure. Code taken from godotengine/godot#42683 # old style
$Button.connect("pressed",this,"myfunc",["watsup"])
# new style
$Button.pressed.connect( myfunc.bind("watsup") )
# annotation style
@connect($Button.pressed, ["watsup"])
func myfunc(extraarg):
print("hello",extraarg) Then passing an array of signals is probably a bad suggestion. Multiple |
I've also got a questionable idea: change the name from Since the connection and the method are close together, we no longer need to name the method conventionally like if self.hit_wall():
self._on_Timer_timeout() Of course, we may/should write an @connect($Timer.timeout)
func explode():
# logic Which is more concise. That's where the @on($Timer.timeout)
func explode():
# logic can be read as a simple English sentence: "On timer timeout, explode". Whereas |
At the moment, I'm not sure if I'd like multi-connect, but of course, it could work having method overloading:
What I've done above requires in some cases obviously varargs—I used |
There is one case I would like to see in this is to connect multiple signals in one go, for ex: var children := get_children()
@connect(children, signal_name, arg)
func on_child_signal(arg):
... In this case it could be hard to specify signal as |
You could make it a different annotation, like so:
Having the first option is preferable IMO because it's more robust for referencing the signal directly instead of a String. |
I'm not against this but it's unlikely to be done for 4.0. I would like to see a more fleshed out proposal. There has been some questions answered in the thread that weren't added to the original post, so it's tough to understand what's actually wanted. For instance:
I personally don't like the idea of connecting multiple signals at once. If you need that just use the annotation multiple times. If you need to connect to all objects in a list, don't use the annotation at all, instead use a I also don't like having multiple meanings for arguments of the annotation. It's hard to understand and really hard to implement. If |
Describe the project you are working on
A generic platformer in GDScript.
Describe the problem or limitation you are having in your project
Declarations of methods that get called by signals are spread apart from the connections to those signals.
If a person wants to find out which signal a method is connected to (or if it is even connected to a signal), they have to go to the
_ready()
method and/or search around the editor through all the signals. It is also possible to use different code editors with Godot which makes it especially hard to track signals connected from the editor.Currently, it is possible to connect any method to any signal from any place in any file potentially leading to tightly coupled design where a child node has
self.signal.connect(parent.method)
-like code making it unable to be reused.Describe the feature / enhancement and how it helps to overcome the problem or limitation
A method targeted
@connect
(EDIT: or@on
; more in comments) annotation that accepts a signal or a list of signals we want to connect this method to. It is placed right above the method so that it is clear from the first glance which signals are connected to this method.The proposed feature also forces a better approach to signals by keeping everything in one place in the parent node.
It declutters the
_ready()
, too.Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
If this enhancement will not be used often, can it be worked around with a few lines of script?
If we talk about convenience, clarity, and visibility, it can't.
Is there a reason why this should be core and not an add-on in the asset library?
It cannot be an add-on since custom annotations are not yet planned to be supported in GDScript.
The text was updated successfully, but these errors were encountered: