[
https://issues.apache.org/jira/browse/THRIFT-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Lee updated THRIFT-2637:
----------------------------
Attachment: fullcamel_service_methods-v2.patch
[~jfarrell] my original late-night reasoning was that "fullcamel" implies the
opposite of "nocamel". Even I was questioning that logic by the time I was done
putting the patch together. :) I think it makes more sense to have an option
that basically says "try to make the code generated from a Thrift IDL look more
like what a reasonable Java developer would expect".
Here's another patch that doesn't bother with a separate option. With the v2
patch applied, specifying the java:fullcamel option will generate both
camel-cased field accessors and service methods.
> "java:fullcamel_service_methods" option to automatically camel-case Java
> service methods
> ----------------------------------------------------------------------------------------
>
> Key: THRIFT-2637
> URL: https://issues.apache.org/jira/browse/THRIFT-2637
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Compiler
> Affects Versions: 0.9.2
> Reporter: Tom Lee
> Priority: Minor
> Attachments: fullcamel_service_methods-v2.patch,
> fullcamel_service_methods.patch
>
>
> [~roger.meier] I hope this isn't too late for the 0.9.2 RC, but it occurred
> to me recently that the java:fullcamel feature which landed in THRIFT-2469
> was only half the picture for Java developers consuming Thrift services from
> other languages. Specifically, accessors would look as you might expect using
> java:fullcamel, but service methods will remain untouched.
> This patch will modify the compiler to add a new option --
> java:fullcamel_service_methods -- which will cause service methods to be
> exposed as camelCase methods. For example: a service method called
> foo_bar_baz becomes fooBarBaz at the source level, while maintaining
> protocol-level compatibility.
> I pondered simply making this the default behavior of the java:fullcamel
> option & simply omitting the new option -- easy enough change to make if
> those semantics are preferred.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
