JCReceiverVariableDecl

[Jonathan Gibbons]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: langtools.patch
Type: text/x-patch
Size: 9818 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20130508/55ee3599/langtools.patch