JCReceiverVariableDecl

[Werner Dietl]

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
>



-- 
http://www.google.com/profiles/wdietl