Allow new line when using chain call. #5890
Replies: 6 comments 2 replies
-
Last time it was proposed, vnen (the main GDScript maintainer) said that it would create confusion with the old base call syntax (because in Godot 3 method calls like this will call the method from parent class). |
Beta Was this translation helpful? Give feedback.
-
Honestly, I really don't see it. It would've been easy to differentiate based on the indentation and context (most classes you may chain calls with are not really designed to be extended with scripts). But now that is This is the kind of proposal that needs little introduction because a lot of GDScript users have gone through this and been forced to either write |
Beta Was this translation helpful? Give feedback.
-
Either allow it for all cases (i.e. not only for chain calls) or forbid it for all cases. Personally I am slightly in favour of the later. Remember: Special cases aren't special enough to break the rules. (quoted from the Zen of Python, also applicable to languages other than Python) But anyway, a way to implement this feature for all cases would be to let a . at the end of the line have the same effect as a \. You would have to write |
Beta Was this translation helpful? Give feedback.
-
Sorry. It may be hypocritical for me to say, considering that I didn't deem the leading self.get_parent().
get_parent().
get_parent().
get_node("somechildren") This is especially true for users with a background of languages that do not split code by indentation. Am I calling It's the same reason as to why I prefer to split multiline operations by beginning the sentence with the operator, instead of trailing it on the previous line. Granted, personal preference, of course. if ( (condition1 and condition2)
or condition3):
pass |
Beta Was this translation helpful? Give feedback.
-
Related to #2201. Moving to discussions, as there is no concrete technical implementation provided. |
Beta Was this translation helpful? Give feedback.
-
This could potentially add ambiguity. var x = my_func()
[1]
# Is it
var x = my_func(); [1]
# or
var x = my_func()[1]
# ?
# ---
var x = my_func()
&"string_name"
# Is it
var x = my_func(); &"string_name"
# or
var x = my_func() & "string_name"
# ? Yes, these examples are contrived. But there is no guarantee that such syntax collisions will not occur in the future. Also, finding where to split statements will complicate the parser unnecessarily. I find explicit parentheses or |
Beta Was this translation helpful? Give feedback.
-
Describe the project you are working on
Now, this kind of code is not available:
this example is stupid. but in other complex cases, this can make code cleaner.
Describe the problem or limitation you are having in your project
it should be a basic gdscript feature
Describe the feature / enhancement and how it helps to overcome the problem or limitation
it helps to shorten long lines
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?
No, it's a gdscript feature.
Is there a reason why this should be core and not an add-on in the asset library?
It's a gdscript feature
Beta Was this translation helpful? Give feedback.
All reactions