godotengine / godot-proposals

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

Move String case conversion methods to core (snake_case, PascalCase, camelCase etc) #719

Closed Xrayez closed 2 years ago

Xrayez commented 4 years ago

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 either PascalCase or camelCase 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 the snake_case.gd needs to be converted to PascalCase 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 the String 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.

Xrayez commented 4 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.

me2beats commented 4 years ago

need them too for creating plugins to convert script paths to class names while they are not there, I've created gdscript methods (gist)

akien-mga commented 3 years ago

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