Normalize case for generated identifiers

[bernardnormier]

Each programming language has its own preferred case convention for identifiers, in particular for member functions/methods and data members/fields/properties/instance variables:

• PascalCase in C#
• camelCase in Java, JavaScript/TypeScript, MATLAB, PHP and Swift
• snake_case in Python
• PascalCase, camelCase or snake_case in C++ depending on which coding style you use

The Slice compilers currently don't change the case of identifiers in the generated code: if you create an interface MyInterface in Slice, you'll get MyInterface in all programming languages. Likewise, if you define an operation myOp (camelCase), you will get a myOp function/method for your proxies and skeletons in all programming languages, and it will look odd in C# and Python.

The Slice naming convention used by ZeroC for Ice and the Ice demos is:

• camelCase for operations, parameter names, data members
• PascalCase for module names, types names (interface, class, struct, enum etc.), constant and enumerators

Ice users are of course free to use whichever naming convention they prefer. For example, it's fairly common to use PascalCase for operation names in Slice and get the same case in the resulting methods/functions.

It would be nice if the generated identifiers could respect the preferred naming convention of each language, instead of generating good looking identifiers in some languages and odd-looking names in other languages.

Proposed solution Add file metadata directives that "normalizes" the case of generated identifiers. The default (without metadata) would be the current behavior: keep the identifiers as-is.

To keep things reasonably simple, I propose a single per-language switch: either the Slice compiler keeps all the identifiers as is, or it normalizes all the identifiers. For example, you would not be able to tell the compiler to normalize the generated identifiers for your operation names but not for your data member names. Furthermore:

• module names would not be transformed. We would introduce instead module metadata to set the name of the corresponding namespace, package, module etc.
• type names and operation parameter names would not be transformed

In other words, this new metadata would affect only the mapping for operation names, data members names, enumerators and constants. In most languages, there would be only one option, for example:

[["java:normalize-case"]] // mapped methods and fields are camelCase
[["cs:normalize-case"]] // mapped methods and properties are PascalCase
[["swift:normalize-case"]] // mapped functions and properties are camelCase
[["python:normalize-case"]] // mapped methods and instance variables are snake_case

In C++, where there is no universal naming convention, the metadata would include the desired convention:

["cpp:normalize-case:camelCase"]] // mapped functions and data members are camelCase
["cpp:normalize-case:PascalCase"]] // mapped functions and data members are PascalCase
["cpp:normalize-case:snake_case"]] // mapped functions and data members are snake_case

[Lastique]

I think, I'd prefer to have a command line argument to select the naming convention on translation instead of putting directives in all .ice files.

[bernardnormier]

I think, I'd prefer to have a command line argument to select the naming convention on translation instead of putting directives in all .ice files.

With the metadata directive(s) directly in the Slice file, you see immediately how this Slice file gets mapped to all language mappings. Using an option to the Slice compilers hides this mapping. For example, we will most likely add the metadata directive ([["normalize-case"]]) to all the Slice files included in Ice, such as Ice/Locator.ice and IceGrid/Admin.ice.

I don't see an obvious use-case for the Slice compiler command-line option. Different groups within a company use different identifier case conventions?

Can you shed light on your use-case?

[Lastique]

The mapping is each user's preference. It follows from coding conventions in the particular project that consumes the generated Slice API. These conventions may be different in different projects on the same language, even within the same company. Note that the Slice API may be published beyond company as well.

Another point for the compiler option is that the option can be specified once in the build system in the Slice generator command line, instead of putting it in every .ice file you have to translate and keeping it consistent everywhere.

[pepone]

Already done for IceRpc C#