Closed Xrayez closed 2 years ago
See also Documentation infrastructure work package section which somewhat supports this proposal:
We need a system to switch references to API methods easily from snake_case to PascalCase, depending on the scripting language you are using.
need them too for creating plugins to convert script paths to class names while they are not there, I've created gdscript methods (gist)
I think that's a good idea, refactoring the existing APIs similar to what is suggested here: https://github.com/godotengine/godot/pull/52141#issuecomment-920654151
Describe the project you are working on: Goost - Godot Engine Extension.
Working on code generators, bindings generators, template engines, and transpilers for Godot Engine. See my gdgen python package for instance.
Describe the problem or limitation you are having in your project: GDScript and core API is written in
snake_case
. This presents a problem for languages which use eitherPascalCase
orcamelCase
conventions, so the entire API needs to be converted (see mono, gdnative/pluginscript modules).Also when working on a GDScript-to-C++ transpiler I immediately stumbled upon an issue with having to convert "unnamed" classes (without
class_name
), so GDScript's file basename which can be written in thesnake_case.gd
needs to be converted toPascalCase
for C++ classes. There are many other use cases ofcourse. Background: #565, #119.Describe the feature / enhancement and how it helps to overcome the problem or limitation: I'd like to see at least the following methods to be added to the
String
class:Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: Some methods are already implemented as used by
mono
module, it's a matter of moving them to theString
class. Preserves names prefixed with/without an underscore, useful for determining private/public access specifiers implicitly. Related: #641.If this enhancement will not be used often, can it be worked around with a few lines of script?: Not a few lines. It's a matter of copy-and-pasting existing implementations if talking about C++ specifically, but additional work is required to port this to GDScript. But mostly, these are not even necessary to expose, it would be enough that those methods can be simply moved to core without exposing them to scripting if they are too specific for most users.
Is there a reason why this should be core and not an add-on in the asset library?: I personally expect this to be present on the core level, yet again it's not necessary for those methods to be exposed to scripting in the first place.