Name casing in generated code

[sveinnthorarins]

Name casing in generated code

[sveinnthorarins]

Okay, yeah I will refactor my schema as that's the easiest option right now.

The feature of converting casing to match coding conventions of the targeted language definitely makes sense. It would be handy to have the docs mention this somewhere though. And, I also couldn't see the docs recommending StrictPascalCase for enum members, would be awesome to add that too.

Thanks Andrew for taking my issue into consideration 😀

[andrewmd5]

Thanks for filing this report. I can see why this is causing some frustration - I should say I’m not opposed to adding a flag that preserves casing, however, in general ambiguous suffixes collide with best practices (not that we’ve outlined them in our documentation anywhere).

I assume you have one definition that you use MessageType as a field in hence combining server and client types into a single enum. Have you considered utilizing a union? It might look something like:

enum ClientMessageType: uint8 {
    ChooseUsername = 20;
}
enum ServerMessageType : uint8 {
  UserJoined = 10;
  UserLeft = 11;
}

union NetworkMessage {
    1 -> message ClientMessage {
        1 -> ClientMessageType type;
    } 
    2 -> message ServerMessage {
        1 -> ServerMessageType type;
    } 
}

and then in you’re code you’re able to do something like:

//type guard
if (decoded.IsServerMessage) {
   console.log(decoded.value.type)
}

[sveinnthorarins]

Well, I haven't looked much at unions but the distinction between actors is not necessarily that important. It just felt nice being able to quickly discern the actor when using the generated enum value constants in code. I also have some both-actor values (like "Error") which would require the third enum type so I think I'd prefer not complicating things with separate enums and a union. Also, I am using a struct, not a message, in an effort to try to take up the least bits possible. Not sure if that complicates using a union even further.

Anyways, the bebop compiler changing casing just felt like it was a little bit too opinionated. Now, to be fair, I felt extra frustrated because it didn't change the casing when I wrote the .bop file. If it did I wouldn't have gone with the "s" and "c" prefixes and maybe would have opted for no prefixes or just "Server" and "Client" prefixes instead. I don't know how I would have felt but I probably wouldn't have been frustrated enough over the compiler's opinions to raise an issue 😄 So yeah, most people probably don't have a problem with the compiler changing casing.

But nevertheless, I still think it is worthwhile to re-evaluate whether the compiler should be forcing a certain name casing opinion and whether the developer should be able to control this behavior. I would fully understand changing the casing if it was necessary to support a certain programming language where casing is a language feature, for example a visibility modifier like in Go. However, if changing the casing isn't strictly necessary, it feels to me like preserving casing and respecting the .bop file would be a better design that allows for more versatility and easier incorporation of bebop types in codebases. At this point thought it is probably better to make the smallest change possible, i.e. adding a flag that preserves casing would be sufficient to allow people to adapt bebop to their needs.

[andrewmd5]

Not sure if that complicates using a union even further.

Unions support messages and structs intermingled.

Anyways, the bebop compiler changing casing just felt like it was a little bit too opinionated.

The goal of the compiler is to generate code that conforms with the conventions of the target language; though TypeScript documentation doesn't make a specific recommendation of enum member naming, they exclusively use StrictPascalCase and UPPER_CASE (both of which are reasonable). We opt for StrictPascalCase which requires making the first character uppercase, and in your case that leads to the oddly formatted members.

The change was more-so a bug fix because we weren’t doing that conversion in a few places in the generator and a corner case caught badly generated code as a result.

Bebop also recommends using StrictPascalCase for enum members because it converts to other cases based on that when targeting other languages.

All that being said, converting of casing to match coding conventions of a given language is a feature, and I’m hesitant to add a new flag that disables it (if I did it would be hidden from —help); I would recommend refactoring your schema to fully spell out Client/Server or restructure to better identify logical bits of data, as it will be a week or so before I can reach a decision.

I appreciate you taking time to explain everything and for being a user