GDScript: access level for class method and class variable

[zjin123]

Closes godotengine/godot-proposals#11039

[dalexeev]

• See also GDScript: Implement soft access restriction for members prefixed with _ and __ (as warning by default) #98557.

[Lazy-Rabbit-2001]

This is a superseding pr of #98136 as well, with extra stuff and access levels implemented.
Sorry but I cannot review yours, dunno why.
You have to rename your accessLevelToString() in snake_case, like access_level_to_string() to make your codes coherent in form with other parts, see DataType::to_string() and DataType::to_string_strict()

[zjin123]

This is a superseding pr of #98136 as well, with extra stuff and access levels implemented. Sorry but I cannot review yours, dunno why. You have to rename your accessLevelToString() in snake_case, like access_level_to_string() to make your codes coherent in form with other parts, see DataType::to_string() and DataType::to_string_strict()

Thanks for pointing out. I will fix the name.

[produno]

Any ideas what's happening with this? Have there been any consensus from the Godot team?

[Lazy-Rabbit-2001]

Any ideas what's happening with this? Have there been any consensus from the Godot team?

Months ago I made an unofficial vote in contributors chat about in which approach the access restriction would be more preferred to be implemented. The result was that most voters preferred adding soft restriction than this pr. However, how to implement access restriction is still a topic in discussion and perhaps there will be a final decision from them after 4.4 stable will be released.

[Leonardo-Ma]

Seems the issue this proposes to solve is the only existing proper encapsulation implementation that follows conventions by other languages with best OO practices, with optional warning and that already requires static typing.

There are at least a dozen of related issues proving this is a very valuable and clearly wanted feature that is very spread with varying opinions and approaches that will probably never be implemented if it keeps like this.
The related oldest and most popular issue was mostly a discussion with no actual suggested implementation.

Soft implementations or annotation only may be worse than no implementation at all. The underscore that is currently the 'workaround' already has these three subjectively bizarre choices (private function / variable, to be overridden also suppress unused).

Encapsulation will already only be used for projects that actually need it by people that minimally understand what they're doing, there is no need for an in between.

Soft or annotation implementation PRs:
Soft: #98557
Soft: #103768
Annotation: #98136 (explanation why it's a bad idea)