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

Add support for annotation blocks in GDScript #5323

Open
SysError99 opened this issue Sep 4, 2022 · 10 comments
Open

Add support for annotation blocks in GDScript #5323

SysError99 opened this issue Sep 4, 2022 · 10 comments

Comments

@SysError99
Copy link

SysError99 commented Sep 4, 2022

Describe the project you are working on

Many HTML5 games that mainly execute GDScript, since I aim for portability and C# doesn't fit the use case. (Godot on HTML5 alone is already very heavy in size compared to any of JS-based game engines)

Describe the problem or limitation you are having in your project

I personally prefer everything that runs in a single script, and treating child nodes as more like "data" rather than composition. I tend to prepare every node in on-ready time in which the script can get access without getting nodes again. In which, Godot already provided @onready annotation keyword, which is very nice and makes code cleaner. However, when nodes become pile-up more and more (which is quite normal for the code that treats child nodes as "data") typing @onready over and over again becomes tedious and time-consuming task (excluding the case of code-typing assistants). This also applies to other annotations that may require the same repetition.

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

Since @onready is one of killing feature over any of the programming languages supported in Godot, both officially and unofficially. Using annotation blocks will help with readability, maintainability, file size, and time-saving in overall code production.

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

Provide an annotation block feature that will consolidate indented lines into the same annotation. The snippet below will use @onready as an example.

@onready var a := 0
@onready var b := "Godot 4.0"
@onready var c := get_node("CanvasLayer/LabelTime") as Label
@onready var d := $ComplexTree/Row25/Col6/Label as Label
@onready var e := HTTPRequest.new()

Will become:

@onready:
    var a := 0
    var b := "Godot 4.0"
    var c := get_node("CanvasLayer/LabelTime") as Label
    var d := $ComplexTree/Row25/Col6/Label as Label
    var e := HTTPRequest.new()

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

I don't think this will be seldom used since it's a key feature of GDScript. Although I may be able to build another transpiler for GDScript, it's still not the same since GDScript is tightly integrated with the game engine.

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

It's directly related to GDScript, it cannot be solved unless I build my own programming language.

@Mickeon
Copy link

Mickeon commented Sep 4, 2022

Since Godot 4 turns onready into an annotation @onready this can probably be expanded to be applicable to all annotations. I remember this behaviour being suggested in the original proposal #828.

It's also not too dissimilar from what other programming languages let you do. Here's a snippet of source code.
image

@YuriSizov
Copy link
Contributor

YuriSizov commented Sep 4, 2022

@Mickeon Annotations stack and are applied to the next statement that takes them. This won't work if you start mixing it with other annotations, like export ones. And making it work would make the code less intuitive at a glance.

Annotations also don't create block context, so this proposal won't be possible to implement with Godot 4 syntax. Not without a rework of annotations.

And IMO, as it doesn't save lines anyway, if you want a bit more organization, you can move assignments to the _ready method for example.

@KoBeWi
Copy link
Member

KoBeWi commented Sep 4, 2022

You don't need to type onready since 3.5. Just drop the node from scene tree to the script while holding Ctrl.

@Calinou
Copy link
Member

Calinou commented Sep 4, 2022

It's also not too dissimilar from what other programming languages let you do. Here's a snippet of source code.

I consider this to be a poor approach as it makes refactoring code harder. You can no longer be certain you're keeping the existing visibility of the member variable when moving code around.

We already have to suffer from poorer-than-usual code refactoring due to the use of indentation for syntax instead of braces – let's not make the problem worse 🙂

@YuriSizov
Copy link
Contributor

I consider this to be a poor approach as it makes refactoring code harder. You can no longer be certain you're keeping the existing visibility of the member variable when moving code around.

Actually, I have to agree, based on my work on the engine. It's often hard to figure out which scope the member has because you need to scroll up and down to find the statement that sets it. It has been quite annoying to me when refactoring some Control and Window code just recently.

@SysError99
Copy link
Author

You don't need to type onready since 3.5. Just drop the node from scene tree to the script while holding Ctrl.

This could be specific but I don't code on Godot's code editor (I use Visual Studio Code), in which the approach isn't favourable in my case.

@YuriSizov YuriSizov changed the title Adding onready block in GDScript. Add support for annotation blocks in GDScript Nov 6, 2022
@hilfazer
Copy link

hilfazer commented Feb 9, 2023

It's also not too dissimilar from what other programming languages let you do. Here's a snippet of source code.

I consider this to be a poor approach as it makes refactoring code harder. You can no longer be certain you're keeping the existing visibility of the member variable when moving code around.

Or the opposite - it could make refactoring easier e.g. for people following official GDScript's style guidelines. I'm moving a method from my protected section to my private section - yup, i want it to have its access modifier changed.

As for not knowing what's the access modifier of the code we're looking at - it's a solved problem.
I remember using some noname Java editor long time ago. It gave the code with different access specifiers different background colours. Godot Editor could do that as well or it could do something different like e.g. using different background colours just on the line numbers.

@Frontrider
Copy link

I believe we need to define how user annotations would work in GDScript, and consider this usecase for it.

@Calinou
Copy link
Member

Calinou commented Feb 9, 2023

I'm moving a method from my protected section to my private section - yup, i want it to have its access modifier changed.

This tends to look confusing in VCS diffs unless the moved line of code is close enough to protected: or private:.

I remember using some noname Java editor long time ago. It gave the code with different access specifiers different background colours. Godot Editor could do that as well or it could do something different like e.g. using different background colours just on the line numbers.

Some external editors may not have this functionality, and we should avoid relying on IDE features being implemented to make something usable.

@shinspiegel
Copy link

Annotations also don't create block context, so this proposal won't be possible to implement with Godot 4 syntax. Not without a rework of annotations.

This is an important point to know.
I would never imagine that it was this level too tight with the line/proximity.
Considering the tab on the lexer I would imagine that this would be a simple feature to implement, but it does not look like it.

This is a feature that I would like to understand more about, I'm not a C++ dev, but with a little bit of guidance (aka.: put my face in the right direction) I could try to check what can be done and how to make this feature available.

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

8 participants