JCReceiverVariableDecl

[Jonathan Gibbons]

By the way, please feel free to comment on or review any of the changes 
I've been making in this area.

-- Jon

On 05/09/2013 05:23 PM, Werner Dietl wrote:
> Thanks for pushing your changes, Jon!
> I notice that class JCReceiverDecl is still in JCTree. Is there a
> reason to keep it around?
>
> cu, WMD.
>
> On Wed, May 8, 2013 at 6:48 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> On 04/10/2013 05:06 PM, Jonathan Gibbons wrote:
>>> Question, on line 867,
>>>          // TODO: do we want a separate tag?
>>>
>>> Answer, yes, and a new Tree.Kind and a corresponding new subtype of Tree.
>>>
>>> Reason: imagine someone wanting to walk the tree -- they need to be able
>>> to get at the "nameexpr" field.
>>>
>>> The alternative would be to pack the qualified name into the "name" field.
>>> The uugh-ness of that depends on what the EG decides for the specification
>>> of the qualified name.
>>>
>>> -- Jon
>>>
>>>
>>>
>>
>> Update, etc,
>>
>> The current JCReceiverVariableDecl is a subtype of JCVariableDecl which adds
>> state, the name expression. This state is not handled in the standard tree
>> utility classes like TreeScanner, TreeTranslator, etc nor is it available
>> from the Compiler Tree API, which all need to be fixed.
>>
>> There are two choices:
>> A) merge JCReceiverVariableDecl into JCVariableDecl, and handle the name
>> expression as a first class field of JCVariableDecl, which is null for all
>> but receiver decls, meaning it should be supported in TreeCopier,
>> TreeScanner, TreeTranslator, and likewise in the com.sun.source API.
>>
>> B) make JCReceiverDecl a first class node, distinct from JCVariableDecl.
>>
>> A is the more elegant solution, but it means that in places, some scanners
>> will have to deal with name expressions.  B is more of a brute force
>> solution and has problems in the parser, where it is assumed that all
>> variables (including receiver parameters) are represented by JCVariableDecl.
>>
>> I still think we should shoot for A.
>>
>> I've attached a partial patch for A, which updates the front end of javac.
>> It does provoke a number of test failures, which need to be addressed (by
>> fixing javac.)
>>
>> Werner, if you want to take a look at this, that would be great, otherwise,
>> I will continue looking at this tomorrow.
>>
>> Either of these options should be able to accomodate decisions from the EG
>> regarding the expressiveness of the name expression, so we are not
>> constrained to wait for this decision.  It would be nice to address this
>> sooner rather than later (next few days) given the upcoming JDK milestone.
>>
>> -- Jon
>>
>
>