[ 
https://issues.apache.org/jira/browse/THRIFT-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162568#comment-14162568
 ] 

Anthony Molinaro commented on THRIFT-2628:
------------------------------------------

So it looks like the feature will be required for anyone who might have been 
coding against the old form.  That means that there should be a big warning in 
the README of the next release telling anyone who currently uses erlang to 
change their Makefile's or whatever they are using to build to include the 
legacynames feature.  My original suggestion of using the feature 'mixed_case' 
to use the new form would have prevented this, but I'm fine with having the 
featureless generation be the newest as long as it's well documented in release 
notes.

> 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
>            Assignee: alisdair sullivan
>              Labels: erlang
>             Fix For: 0.9.2
>
>
> 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.3.4#6332)

Reply via email to