[
https://issues.apache.org/jira/browse/THRIFT-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565992#comment-14565992
]
Jens Geyer commented on THRIFT-3170:
------------------------------------
No movement here ... as I see it, we have three opinions "pro flagification".
So all we need is a PR or patch to be reviewed and finally accepted by all
sides.
> 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)
