thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gregory_l...@selinc.com
Subject Re: Camel Casing in C#
Date Tue, 30 Dec 2014 19:45:34 GMT
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" <jensgeyer@hotmail.com>
To:     <user@thrift.apache.org>
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: gregory_lusk@selinc.com
Sent: Tuesday, December 30, 2014 3:55 PM
To: user@thrift.apache.org
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 <jensgeyer@hotmail.com>
To:     "user@thrift.apache.org" <user@thrift.apache.org>
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: gregory_lusk@selinc.com
Gesendet: 30.12.2014 00:52
An: user@thrift.apache.org
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








Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message