[
https://issues.apache.org/jira/browse/THRIFT-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295604#comment-14295604
]
ASF GitHub Bot commented on THRIFT-2939:
----------------------------------------
Github user malandrew commented on the pull request:
https://github.com/apache/thrift/pull/353#issuecomment-71891630
Good to see these changes. I encountered some of the same issues. I hacked
around for a few days and ported all the browser features to the nodejs
codebase for use with browserify. There is a massive diff here,
https://github.com/uber/thrift/commit/9ca44b40504cc8d45d0c1e47709128e474d991df
, but I'm going to work over the next day or so to break this monolithic commit
up into smaller commits capturing all the changes I made.
> JavaScript generated code for Node and browser is different
> -----------------------------------------------------------
>
> Key: THRIFT-2939
> URL: https://issues.apache.org/jira/browse/THRIFT-2939
> Project: Thrift
> Issue Type: Improvement
> Components: JavaScript - Compiler, JavaScript - Library
> Affects Versions: 0.9.2
> Reporter: Radoslaw Gruchalski
> Labels: javascript, patch
>
> The generated code for regular JS differs from NodeJS code. NodeJS uses
> direct return values from {{read<Type>()}} while regular JS code expects a
> value from {{read<Type>()}} to be an object with {{.value}} property.
> This makes it impossible to share generated code between browser JS and
> NodeJS. The fix is rather simple:
> - do not append {{.value}} in generated code while accessing values read from
> protocol / transport
> - do not return an object with the value property from {{read}}, return
> result read
> I am not sure why such difference. Both environment implementations take an
> input, which is a protocol, and execute the same read methods. There is no
> need to have an additional complexity in regular JS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
