[
https://issues.apache.org/jira/browse/THRIFT-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066104#comment-14066104
]
alisdair sullivan commented on THRIFT-2628:
-------------------------------------------
i missed that the thrift definitions did not have repeated names and that the
problem was specifically the erlang representation (or rather the normalization
as atoms)
what exactly is allowed as a thrift field name? ideally,
{code}
struct foo {
1: string bar,
2: string Bar
}
{code}
would compile to:
{code}
-record(foo, {bar :: string() | binary(),
'Bar' :: string() | binary()}).
{code}
or
{code}
-record(foo, {bar :: string() | binary(),
<<"bar">> :: string() | binary()}).
{code}
but not all thrift field names may be representable by either of these schemes
and normalization/conversion may introduce further conflicts
also note this would probably have to be gated behind a generator option as
anthony suggests to preserve backwards compatibility
> erlang: struct member name conflicts due to lowercased 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)
