[
https://issues.apache.org/jira/browse/THRIFT-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988169#action_12988169
]
Bryan Duxbury commented on THRIFT-1050:
---------------------------------------
I like the #1 option. Rather than trying to make up a phrase that's really
obscure, I'd favor using some bizarre prefix like ___ (triple underscore) that
no sane person would ever want in their arguments.
> Declaring an argument named "manager" to a service method produces code that
> fails compile due to name conflicts with protected ivars in TAsyncClient
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-1050
> URL: https://issues.apache.org/jira/browse/THRIFT-1050
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler, Java - Library
> Affects Versions: 0.5
> Reporter: Tony Kinnis
> Priority: Minor
> Fix For: 0.7
>
>
> The java code that is generated for a service method that has a argument
> named "manager" fails to compile. The TAsyncClient class declares a protected
> instance variable named "manager" and the generated code for the async call
> of that method declares a parameter called manager and also tries to use the
> instance variable called to dispatch the async call, however it can't since
> the method argument is shadowing the instance variable.
> Here is an example of the invalid code that is generated.
> {code}
> public void savePerson(Person manager, AsyncMethodCallback<savePerson_call>
> resultHandler) throws TException {
> checkReady();
> savePerson_call method_call = new savePerson_call(manager, resultHandler,
> this, protocolFactory, transport);
> manager.call(method_call); // XXXX This is where the compile error occurs
> }
> {code}
> I think having a argument named "manager" could be fairly common.
> There are two potential fixes to this problem.
> 1. rename TAsyncClient's instance variable to something more obscure and less
> likely to collide, like asyncClientManager
> 2. make the variable private and access it via a method
> I think changes would need to be made in TAsyncClient.java as well as the
> code generator.
> There are two other member variables with protected access that could also
> create similar conflicts.
> protocolFactory
> transport
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
