"Exposed" properties and signals in GDScript

[SimplyBLGDev]

Describe the project you are working on

Any project with many nodes and sub-scenes

Describe the problem or limitation you are having in your project

Under current limitations I find myself creating many intermediate scripts whose only functionality is exposing some of their children properties, specially when creating UI.
In order to follow SOLID principles and creating consistent interfaces on sub-scenes this ends up happening a lot, not only would a simpler way to do this lead to a faster workflow but it would encourage clean coding principles that are standard in most development environments.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

A unique modifier similar to @export (possibly something like @expose or @forward) that allows for a property or signal to be directly linked to one of their children.

• In the case of properties this would act as a getter and setter for a property on one of the scene's children
• In the case of signals it would forward the signal whenever emitted

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

As you can see in this almost-real node structure there are many sub scenes, some are used in order to allow multiple instances, like party_action_button and character_actions_row while others just act as an interface with the rest of the game, like party_container and battle_ui

On this second example we have a script whose only function is to act as an interface that exposes some properties to the exterior, hiding the rest of the properties of it's children nodes and exposing sprite_with_frames/frame, allowing the rest of the nodes to interact with sprite_frame_synchronizer without worrying about the node structure of it's children

This feature would transform sub-scenes into their own object that only exposes relevant data to the outside

If this enhancement will not be used often, can it be worked around with a few lines of script?

In the case of signals connect()ing the child's signal when instanced and emit_signal() whenever the child emits that signal.
In the case of properties (for the example above)

@export var value: int:
	get:
		return $sprite_with_frames.frame
	set(new_value):
		$sprite_with_frames.frame = new_value

Is there a reason why this should be core and not an add-on in the asset library?

This would be very useful in every project and it allows for cleaner, more organized code as well as facilitating the implementation of design principles.
It would also be more efficient the core because in the case of properties the @tool modifier wouldn't be necessary to see the changes in the editor (which would be a desirable outcome) and because both signals and properties wouldn't even need their own code and memory allocation, they can just be a pointer, something trivial in C++ but impossible from outside the core.

[AThousandShips]

@Mano-East Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

Especially when this was just opened 🙃

[ghost]

This is interesting, it's also quite common in my workflow to "expose" signals.

But I don't really like the solution, I would prefer some kind of "property reference" and "signal reference" like below:

# Child node Script
var prop
signal sig

# Base node Script
@onready
var prop = $child::prop

@onready
signal sig = $child::sig

[SimplyBLGDev]

This is interesting, it's also quite common in my workflow to "expose" signals.

But I don't really like the solution, I would prefer some kind of "property reference" and "signal reference" like below:

# Child node Script
var prop
signal sig

# Base node Script
@onready
var prop = $child::prop

@onready
signal sig = $child::sig

I like the syntax however I would point out that it's important in the case of properties that they work in the editor so I'd hesitate to have them be @onready

[theraot]

Related:

• Automate or reduce the boilerplate when forwarding script properties in GDScript #6750
• Add a way to export children's properties to editor through "linked" variables #3133
• Add synchronized variables / pointers without functions #2817

[ditiem-games]

I like the syntax however I would point out that it's important in the case of properties that they work in the editor so I'd hesitate to have them be @onready

I agree with you. I think you should use another keyword like @outbound OR @onready export

@outbound 
var cancel_button: Button = $cancel_btn

@outbound 
signal on_cancel_pressed = $cancel_btn.pressed

@outbound
var cancel_prop: String = $cancel_btn.script_property

An interesting point is whether a scene should recursively export all the sub-scenes outbounds or not: outbound.public vs outbound?

[SimplyBLGDev]

An interesting point is whether a scene should recursively export all the sub-scenes outbounds or not: outbound.public vs outbound?

No, the sub-scene "outbounds" should be hidden by default, after all the whole point of this feature is to allow the definition of an external interface according to the user's needs, of course one could always chain outbounds if required