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
class_nameParentextendsNodefunc_ready() ->void:
print("Hello from Parent")
extendsParentfunc_ready() ->void:
super._ready() # Private method "_ready" has been called (private-method-call)print("Hello from Child")
I was looking around to see if calling super._ready() or super._process(delta) was a bad practice, but from what I've read it seems to be a relatively common way of doing things. So ideally I think calling private methods on super should be fine.
I think this is a more general problem with this rule. In gdscript the styleguide says you should start the name of virtual methods with an _, even if the methods are intended to be public. Using the same character for two different meanings makes it pretty difficult to handle with a linter/formatter.
Maybe it is worth removing this rule from the linter?
I think this is a more general problem with this rule. In gdscript the styleguide says you should start the name of virtual methods with an _, even if the methods are intended to be public. Using the same character for two different meanings makes it pretty difficult to handle with a linter/formatter.
Maybe it is worth removing this rule from the linter?
Yes, I'll probably remove that rule as it makes very little sense in case of GDScript
I made a proposal to update the style guide. Not sure if it will go anywhere yet but I figured it was worth sharing here as it is directly related to this issue.
Here's an example of the use-case implementation
I was looking around to see if calling
super._ready()
orsuper._process(delta)
was a bad practice, but from what I've read it seems to be a relatively common way of doing things. So ideally I think calling private methods onsuper
should be fine.Similar to #283
The text was updated successfully, but these errors were encountered: