[
https://issues.apache.org/jira/browse/THRIFT-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14063919#comment-14063919
]
Anthony Molinaro commented on THRIFT-2628:
------------------------------------------
The description for this ticket is confusing because you say 'repeated keys',
and I immediately thought 'those shouldn't be allowed' and tried
{noformat}
struct foo {
1: string bar,
2: string bar
}
{noformat}
Which when compiled with master gave
{noformat}
[ERROR:/Users/molinaro/projects/opensource/thrift-env/foo.thrift:4] (last token
was '}')
"2: bar" - field identifier/name has already been used
{noformat}
I then noticed that what is actually the problem is the lowercasing of record
fields causing a conflict. So an actual failing case is something like
{noformat}
struct foo {
1: string bar,
2: string Bar
}
{noformat}
Which could be fixed by providing a generator option for erlang, called
'mixed_case' which just adds single quotes around all record keys and skip
lowercasing anything, because while the current record definition for the
second 'foo' struct above is currently this
{noformat}
-record(foo2, {bar :: string() | binary(),
bar :: string() | binary()}).
{noformat}
which does not compile, you could generate
{noformat}
-record(foo2, {'bar' :: string() | binary(),
'Bar' :: string() | binary()}).
{noformat}
which would compile fine. By introducing a generator option, you could
preserve current behavior for current invocations of 'thrift -gen erl', but get
the new form with 'thrift -gen erl:mixed_case'.
> erlang backend doesn't support repeated names
> ---------------------------------------------
>
> Key: THRIFT-2628
> URL: https://issues.apache.org/jira/browse/THRIFT-2628
> Project: Thrift
> Issue Type: Bug
> Components: Erlang - Compiler, Erlang - Library
> Reporter: alisdair sullivan
> Labels: erlang
>
> the erlang backend generates records to represent structs. instead of the
> unique sequential id they use the struct field name as the record keys.
> records in erlang do not support repeated keys so generated erlang modules do
> not compile
> the most obvious fix is to refuse to generate code from structs with repeated
> keys but this means the erlang backend is not capable of handling all valid
> structs
> the easiest fix is to switch structs to use the unique sequential ids as the
> keys of the record but this breaks backwards compatibility and probably
> necessitates generating helper functions to retrieve fields by name
> also possible is switching to an erlang data structure that supports repeated
> keys but this would also require breaking backwards compatibility
--
This message was sent by Atlassian JIRA
(v6.2#6252)
