You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It should be possible to re-write the signal support so that Swift-side signals are implemented using the same helper classes as imported ones. This should result in a more uniform interface, and less code.
This could be a breaking change (if we alter the #signal macro), but I think it could probably be done instead as an additive change, using a different macro (possibly @Signal). Any implementation would probably be built on top of #42.
The text was updated successfully, but these errors were encountered:
A solution should result in syntax more like this:
@GodotpublicclassSBActor:Object{@SignalvarweaponsChanged// signal will be exposed to Godot as "weapons_changed"func changeWeapon(_ weapon:SBWeapon){
weaponsChanged.emit()}}@GodotpublicclassSBHud:Object{func connectToActor(_ actor:SBActor){actor.weaponsChanged.connect{// update the HUD UI here...}}
It should also support signal parameters properly:
@GodotpublicclassSBActor:Object{@Signal(args:[Int.self])varhealthChanged// signal will be exposed to Godot as "health_changed, <new-health>"func hit(_ amount:Int){
health -= amount
healthChanged.emit(health)}}@GodotpublicclassSBHud:Object{func connectToActor(_ actor:SBActor){actor.healthChanged.connect{ health in// update the HUD UI here...}}
Imported Signals
When we import a signal from Godot, we generate a helper class and a computed property, which allows us to connect to it in a very Swift-like manner:
If the signal has parameters, these are surfaced correctly in the closure:
Signals Defined In Swift
However, when we define a signal in Swift using the
#signal
macro, we create a static property on the Swift class.This requires a different, less intuitive, less idiomatic syntax for connected to or emitting signals:
It should be possible to re-write the signal support so that Swift-side signals are implemented using the same helper classes as imported ones. This should result in a more uniform interface, and less code.
This could be a breaking change (if we alter the
#signal
macro), but I think it could probably be done instead as an additive change, using a different macro (possibly@Signal
). Any implementation would probably be built on top of #42.The text was updated successfully, but these errors were encountered: