godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.16k stars 97 forks source link

Improve StringName and NodePath usability #4721

Open KoBeWi opened 2 years ago

KoBeWi commented 2 years ago

Describe the project you are working on

A very big project I am converting to 4.0

Describe the problem or limitation you are having in your project

Godot 4.0 added StringNames as a type usable from GDScript. Many methods now expect StringNames (implicit String conversion is available though), but StringNames are also nice for custom methods that rely a lot on string comparisons, but don't modify the strings. So my code keeps getting new StringNames everywhere.

Another thing are NodePaths, which are used in some methods too. I neglected them so far, because when you use String it will just get automatically converted when needed, but using correct type makes the code faster and it doesn't hurt to use it.

My only problem is that syntax-wise StringNames and NodePaths are basically Strings with extra symbol at the beginning. This is nice for converting project, because you can just slap & to your strings, but not very convenient for new code and also it's less readable (mostly due to being colored the same as Strings and the extra symbol standing out).

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

We have a special coloring for $ operator: image

It should be the same for & and ^, i.e. StringName and NodePath could get their own unique color, so instead of image we could have image (ignore that the symbol is darker; it should be the same)

And since % got it's special syntax (%UniqueNode), we could allow unquoted StringNames and NodePaths too: image

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

Allow this and make it uniquely-colored in the script editor:

&StringName
^NodePath

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

Syntax part can be worked around by using quotes 🙄 but the custom highlighting part not.

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

StringName and NodePath are core types.

YuriSizov commented 2 years ago

(ignore that the symbol is darker; it should be the same)

But I kinda like it... 👀

Calinou commented 2 years ago

I like the idea, but this may add a lot more colors for third-party syntax themes to support – especially with the leading symbols. Maybe the leading symbol color can be automatically generated using a lower opacity than the base color for StringName and NodePath.

And since % got it's special syntax (%UniqueNode), we could allow unquoted StringNames and NodePaths too:

I don't think that's a good idea. It starts to remind me of Ruby, and not in a good way. At the end of the day, StringNames are still strings – the different type is mainly here for performance reasons.

YuriSizov commented 2 years ago

Maybe the leading symbol color can be automatically generated using a lower opacity than the base color for StringName and NodePath.

Yes, that's how I'd like to see it work.

KoBeWi commented 2 years ago

tbh I don't like the idea of darker symbols. It's just unnecessary. Although with quotes maybe makes sense; you get a different-colored string and actually the symbol becomes redundant. Or something.

It starts to remind me of Ruby, and not in a good way.

Ruby is great tho. I don't see any problem in skipping quotes; they are useless.

this may add a lot more colors for third-party syntax themes to support

Why is this even relevant xd They can just set the same color for every option.

SilencedPerson commented 2 years ago

(ignore that the symbol is darker; it should be the same)

But I kinda like it... 👀

I have to agree on this, I would love this on the $ syntax, I tend to avoid it, because the symbol makes it very hard to read, the darker version remedies this substantially.

MewPurPur commented 2 years ago

This can be closed, right?

KoBeWi commented 2 years ago

No, the second part of the proposal (unquoted StringNames and NodePaths) is still not addressed.

MewPurPur commented 2 years ago

Ah mhm. Not too fond of the idea personally, I think it's nice to be clear those are just special types of strings. For NodeRefs ($MyNode) it's fine, but for NodePath and StringName there are autoconversions with Strings.

I suppose we'd need to make symbols like / and % special cases to continue NodePaths.

StringName plays nicely with most of the ways it's used in the editor, but a few are still problematic, like get and set on a property with slashes. I personally wouldn't use it without quotation marks though. For example it's a common practice to use special symbols for translatable strings, which get passed to tr(StringName). Even if not, some of my uses of StringName are with whitespaces, which is perfectly normal for them, but not fine should I avoid quotations.

dalexeev commented 1 year ago

The literals are already highlighted in different colors:

Allow this and make it uniquely-colored in the script editor:

&StringName
^NodePath

This syntax can confuse users into thinking that pointers/references exist in GDScript:

node_2d.set(&global_scale, Vector2(8, 2.5))
tween.tween_property($Sprite, ^position, Vector2(100, 200), 1)

The quotes more clearly indicate that these are just special strings:

node_2d.set(&"global_scale", Vector2(8, 2.5))
tween.tween_property($Sprite, ^"position", Vector2(100, 200), 1)