VariableTree.getNameExpression and TreeScanner

[Jonathan Gibbons]

Werner,

The way to look at this is that a receiver "declaration" is different from
other parameter declarations, and needs to be handled as such.

For a "normal" parameter declaration, the nameExpression will always be 
null.
For a receiver "declaration", the nameExpression will never be null.

The alternative, which I did consider, would have been to have a totally 
separate
new tree node for the receiver.  However, that had a much bigger impact 
on the
API than adding a nameExpression to VariableDecl for use by receiver 
"declarations".

If you wish to ignore the nameExpression, you need to override 
visitVariableDecl
and visit the other parts of the declaration, omitting the nameExpression.

-- Jon


On 05/23/2013 10:58 AM, Werner Dietl wrote:
>>> Why is it desirable to traverse the receiver parameter name, which is
>>> usually simply "this"?
>> Because it might not be "this".
>>
>> What if you were using a TreeScanner to create a custom pretty printer?
> Then you have to handle parameter names separately anyway, because, as
> you point out below, the parameter names are not visited by a
> "visitIdentifier".
> So one could argue that it might be surprising that you get a new
> "visitIdentifier" call for the "this" name or some other calls for the
> more complex receiver name expressions.
>
> Either way is fine with me.
>
> cu, WMD.
>
>
>
>>> Should other parameter names also be visited, for consistency?
>>
>> Other parameter names are represented by Name, not a tree node, so they
>> can't be visited.  The nameExpression is only set for a receiver parameter
>> and is null the rest of the time, much like the "default" value on a method
>> decl is only set for a "method" in an anno decl.
>>
>> -- Jon
>
>
> --
> http://www.google.com/profiles/wdietl