[
https://issues.apache.org/jira/browse/THRIFT-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284240#comment-16284240
]
Jens Geyer edited comment on THRIFT-4410 at 12/8/17 9:29 PM:
-------------------------------------------------------------
The compiler generates code for the args you pass to a service method and the
result(s) you get from it.
{code}
i32 Foo( 1: string arg1, 2: i8 arg2) throws (1: SomeError se, 2:
TheOtherError toe)
{code}
You may ask, why we need a structure for results, as there is only one return
value? In the result structure there is one field for the function result, and
0-N fields for exceptions declared and potentially thrown. These structures are
named by a predefined naming scheme which may conflict with fields .
THRIFT-2009 was initially about a similar problem, where the generated
{{NewXxx}} functions could conflict with field names as well, but it became
clear quickly that the issue is larger than originally assumed.
To be clear, the conflict is not the fault of the IDL writer. Instead, the
underlying problem is far more generic, as there are possible conflicts with
keywords in other languages as well. Some of these keywords are forbidden and
blocked by the compiler (those who make problems in a lot of languages) and
some are handled via the "underscore" method on a per-language level.
Again, if you have a better idea how to handle it, ideally in an
non-compatibility breaking way, please don't hesitate to send pull requests.
was (Author: jensg):
The compiler generates code for the args you pass to a service method and the
result(s) you get from it.
{code}
i32 Foo( 1: string arg1, 2: i8 arg2) throws (1: SomeError se, 2:
TheOtherError toe)
{code}
You may ask, why we need a structure for results, as there is only one return
value? In the result structure there is one field for the function result, and
0-N fields for exceptions declared and potentially thrown. These structures are
named by a predefined naming scheme which may conflict with fields .
THRIFT-2009 was initially about a similar problem, where the generated
{{NewXxx}} functions could conflict with field names as well.
To be clear, the conflict is not the fault of the IDL writer. Instead, the
underlying problem is far more generic, as there are possible conflicts with
keywords in other languages as well. Some of these keywords are forbidden and
blocked by the compiler (those who make problems in a lot of languages) and
some are handled via the "underscore" method.
Again, if you have a better idea how to handle it, ideally in an
non-compatibility breaking way, please don't hesitate to send pull requests.
> Extra ending underscore with field ending with `result` for Golang
> ------------------------------------------------------------------
>
> Key: THRIFT-4410
> URL: https://issues.apache.org/jira/browse/THRIFT-4410
> Project: Thrift
> Issue Type: Question
> Components: Go - Compiler
> Affects Versions: 0.10.0
> Environment: macos high sierra
> Reporter: Bob Cao
> Priority: Trivial
>
> Given a struct where fields ending with {{result}}
> {code}
> struct Test {
> 1: optional string id_result
> 2: optional string name_result
> 3: optional string full_description_result
> 4: optional string image_url_result
> }
> {code}
> The generated go codes are
> {code:go}
> type Test struct {
> IDResult_ *string `thrift:"id_result,1" db:"id_result"
> json:"id_result,omitempty"`
> NameResult_ *string `thrift:"name_result,2" db:"name_result"
> json:"name_result,omitempty"`
> FullDescriptionResult_ *string `thrift:"full_description_result,3"
> db:"full_description_result" json:"full_description_result,omitempty"`
> ImageURLResult_ *string `thrift:"image_url_result,4" db:"image_url_result"
> json:"image_url_result,omitempty"`
> }
> {code}
> I am expecting the field has the same name as defined (no undersore at the
> end).
> Thanks [~jensg] for pointing out the codes, if anyone could en-light me
> about why IDL identifiers end with "Args"/"Result" interferes with the
> implicit service, that will be much appreciated!!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
