[ https://issues.apache.org/jira/browse/THRIFT-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567815#comment-14567815 ]
ASF GitHub Bot commented on THRIFT-3170: ---------------------------------------- Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/508 > Initialism code in the Go compiler causes chaos > ----------------------------------------------- > > Key: THRIFT-3170 > URL: https://issues.apache.org/jira/browse/THRIFT-3170 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler > Affects Versions: 0.9.2 > Environment: Go/C++/Java > Reporter: Adam Beberg > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > The code introduced in THRIFT-3027 (now closed) created issues. > 1. It's inconsistent. Compare thrift name and Go names: > {code} > type Foo struct { > Id int32 `thrift:"id,1" json:"id"` > MyID int32 `thrift:"my_id,2" json:"my_id"` > NumCPU int32 `thrift:"num_cpu,3" json:"num_cpu"` > NumGpu int32 `thrift:"num_gpu,4" json:"num_gpu"` > My_ID int32 `thrift:"my_ID,5" json:"my_ID"` > } > {code} > CPU vs Gpu, Id vs ID, ... > 2. It's one-way. This is a serious problem. Go code dealing with databases > and other things assumes convertibility between snake_case and CamelCase in > both directions for things like SQL column names. This breaks that. > 3. Generated code is explicitly NOT subject to this in the Go initialism > guideline, for good reasons. > "Code generated by the protocol buffer compiler is exempt from this rule. > Human-written code is held to a higher standard than machine-written code." > 4. Working across Go/C++/Java, these inconsistencies are really messing with > engineers that aren't as familiar with Thrift internals, which will > inevitably lead to mistakes, so it's a usability issue. > My recommendation: Strongly suggest removing the initialism rewriting code, > those wanting initials in caps can still specify them in the thrift > definitions without any problems in Go (but then Java has problems). If not > make it a command line option usable by those working only in Go without > other dependencies, but that still leaves problems 1 & 3. > I can quickly prepare a patch to remove or flag-ify, but would like > discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)