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
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:
snake_to_camel_case
snake_to_pascal_case
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: