Hi Jens, >If you talk about communicating via Thrift-serialized structures, this is
>actually not the case. Thrift identifies struct properties and arguments not >via name, but via 32 bit numbers, a.k.a field IDs. This makes the whole >thing independent from any actual language representation. Even if an >(hypothetical) language would allow for uppercase letters only, it would >still be possible to exchange data with another language that allows for >lowercase letters or say, egyptian hieroglyphes, only. The mapping in the >wire format is entirely done via the field ID. So to make sure that I understand you correctly, if I generate a C# implementation using a Thrift IDL, and communicate with my embedded firmware product using Thrift's JSON protocol and HTTP transport and on the embedded side there is no Thrift, there will still be compatibility? >Fun aside: You cannot seriously expect any OSS or commercial project to >adhere to your (basically arbitrary) corporate standards. There are >thousands of companies out there, with probably millions of permutations of >such standards. Currently, with Thrift all languages' code generators >implement their own, hard-coded way how IDL properties are translated into >code. There is no template system or the like (this would make some things >easier). I agree that this is too much to ask of a tool like Thrift to adhere to without some templating feature, which is why I caveated my statement. :) But it does bring up a bigger point, which is that there are preferences that users might want to realize in the generation. Pipeline programming in D is one example. I suppose that in this case, though, forking and customizing is the way to go. I think that if we can ensure that we have compatibility between the code generated by the Thrift compiler and our existing firmware code, then we'll just stay with the generated code. Otherwise, we will need to implement some type of post-parser that enforces our basic code requirements. Thanks, Greg From: "Jens Geyer" <[email protected]> To: <[email protected]> Date: 12/30/2014 01:54 PM Subject: Re: Camel Casing in C# Hi Greg, > [...] > our embedded firmware products [...] written in C > [...] > The data types in the firmware use lower case, > underscored field names, so when we generate > the C# classes, there is inherent incompatibility > between the firmware and software. If you talk about communicating via Thrift-serialized structures, this is actually not the case. Thrift identifies struct properties and arguments not via name, but via 32 bit numbers, a.k.a field IDs. This makes the whole thing independent from any actual language representation. Even if an (hypothetical) language would allow for uppercase letters only, it would still be possible to exchange data with another language that allows for lowercase letters or say, egyptian hieroglyphes, only. The mapping in the wire format is entirely done via the field ID. > and we're exchanging more complex > types rather than simple native types Doesn't matter. As long as you express it in Thrift IDL the above statement holds. > how do we customize the generated code > to meet our corporate standards Oh, that's easy: Change your corporate standards :-) Fun aside: You cannot seriously expect any OSS or commercial project to adhere to your (basically arbitrary) corporate standards. There are thousands of companies out there, with probably millions of permutations of such standards. Currently, with Thrift all languages' code generators implement their own, hard-coded way how IDL properties are translated into code. There is no template system or the like (this would make some things easier). > My thought was to start with command line switches > for the generator, like the ones that are used when > generating Java source. Was my first thought as well, but I don't think it is a good idea anymore. Just try to answer the question: How would you name and describe the new switch? -gen csharp:corpXYZ Generate code that adheres to the arbitarily chosen style guide of company XYZ The only option which (IMHO) really would add value to Thrift would be either something like a (probably complex) template feature, or a much simpler version which uses some kind of pre-defined rules that can be easily put into a text file: -gen csharp:style=<file> Generate code that adheres to the coding rule set given in <file> But even that involves some work, that's for sure. Back on main topic: What options do we have if you still need it? - There are some extensions, mostly in the C++ area, which employ annotations to get specific behaviours. Could be another way. - Accept the fact that Thrift does not meet the corporate standards, use the arguments above and convince the management. - Private fork to implement the changes you need. I'm not a big fan of it (personal opinion), but it is still a valid solution. What do you think? Have fun, JensG PS: Interesting topic, anyway. -----Ursprüngliche Nachricht----- From: [email protected] Sent: Tuesday, December 30, 2014 3:55 PM To: [email protected] Subject: Re: AW: Camel Casing in C# It's a bit of a problem. One of our use cases is that we have an existing service contract with one of our embedded firmware products that is written in C. We'd like to use the Thrift IDL to specify the structures and services themselves. The data types in the firmware use lower case, underscored field names, so when we generate the C# classes, there is inherent incompatibility between the firmware and software. Admittedly, this is an abbreviation of the purpose of Thrift in that we are not using RPC to transfer values, and we're exchanging more complex types rather than simple native types. But the issue with casing uncovers a related question: how do we customize the generated code to meet our corporate standards. Is hacking the Thrift generator source code the only way? Maybe some sort of simple class template file could do the trick. My thought was to start with command line switches for the generator, like the ones that are used when generating Java source. Thanks, Greg From: Jens Geyer <[email protected]> To: "[email protected]" <[email protected]> Date: 12/30/2014 03:35 AM Subject: AW: Camel Casing in C# Hi Gregor, no, unfortunately not. All available switches are listed on the thrift --help screen. Is that a problem with your use case? Have fun, JensG ________________________________ Von: [email protected] Gesendet: 30.12.2014 00:52 An: [email protected] Betreff: Camel Casing in C# Can anyone tell me if it is possible to turn on and off camel casing on property names when generating C#? Basically, if I have a field called "general" in my .thrift file, I want a property called, "general" in my C# file. Instead, I get a property called "General". Thanks, Greg Lusk
