Community
Participate
Working Groups
It appears that org.eclipse.jdt.core.dom converts all field references to SimpleName or QualifiedName, unless they are proceeded by a "this." Even access to static fields proceeded by the Class name, See the example output and code below: DEBUG [ModalContext] - Name = sf_hi DEBUG [ModalContext] - Name = FieldRef.sf_hi DEBUG [ModalContext] - Name = FieldRef DEBUG [ModalContext] - Name = f_hi DEBUG [ModalContext] - FieldAccess = this.f_hi public class FieldRef { static String sf_hi = "HI"; String f_hi = "HI"; void test() { // static field sf_hi = "HI"; FieldRef.sf_hi = "HI"; // field f_hi = "HI"; this.f_hi = "HI"; } public static void main(String[] args) { FieldRef fr = new FieldRef(); fr.test(); } } First problem, the JavaDoc leads one to believe that everything should show up in a FieldAccess not just the "this." case, hence the documentation needs to be beefed up. Second problem, I understand the difficulty of figuring out if something is a FieldAccess vs Type vs nested class field, etc... without binding, hence my proposal is that FieldAccess should get the axe. FieldAccess is currently used for a special case only and it implys binding knowledge if it is not only used in that special case. It leads the user to believe that all FieldAccess's will show up as this node. My proposal is to remove FieldAccess and change all ASTNode instances that today show up as FieldAccess into a QualifiedName. Thoughts? Another possiblity is that FieldAccess become a child-class of QualifiedName so this strangeness can be ignored if desired. Take Care, Tim Halloran
The grammar rules state what a field access is versus a qualified name. The DOM AST truly reflect the source code nature. The fact that a given name is then bound to a particular field requires some name resolution to happen, which is only optional for the DOM AST, and somewhat a separate concern from what it represents syntactically. Your proposal would not be optimal in the sense as qualified names would need to accomodate token identifiers like 'this' which are reserved keywords (and thus forbidden in there). Furthermore, you would still need field accesses to represent constructs like "new A().x". This being said, the documentation should better clarify this.
Olivier - please double check the documentation for better clarifying this issue.
*** Bug 22377 has been marked as a duplicate of this bug. ***
Concur with your thinking -- The JavaDoc needs to cover: (1) Most actual field accesses will really be Names (with some discussion of the need for binding information which is not always there, bla bla...) -- see point (3) below, they maybe should be described together (2) FieldAccess exists ONLY for some very specific cases a) this.field b) new A().field ??? any others -- lets be very clear ??? (3) That Name (SimpleName, QualifiedName), SuperFieldAccess are required to be examined to find all field accesses...E.G., what is the set of ASTNode's that represent all field accesses. This problem is more a documentation problem than a technical problem, thanks for the clarification (and the duplicate bug points suggests I was not the only confused one:-) Take Care, Tim
There are two angles: (1) the node types available to represent Java source code (2) the particular choices of node types that parseCompilationUnit chooses to represent the Java source code it was fed. We do need to improve the documentation to make it clear that there are choices for how to represent expressions involving ".", and explain which arrangement of nodes are legit and which ones are not; and we should point out where there are multiple correct answers. "x.y" is one instance that could be represented either as a FieldAccess or as a QualifiedName - both are equally acceptable. parseCompilationUnit is free to return either, and it should remain open as to which form it chooses. Without loss of generality, callers of parseCompilationUnit should be prepared to handle any legit result, and not assume that the parser systematically prefers one form over another.
Jim - Could you please update the doc to clarify this issue?
Added the following clarification to javadoc for FieldAccess class: * Note that there are several kinds of expressions that resemble field access * expressions: qualified names, this expressions, and super field access * expressions. The following guidelines help with correct usage: * <ul> * <li>An expression like "foo.this" can only be represented as a this * expression (<code>ThisExpression</code>) containing a simple name. * "this" is a keyword, and therefore invalid as an identifier.</li> * <li>An expression like "this.foo" can only be represented as a field * access expression (<code>FieldAccess</code>) containing a this expression * and a simple name. Again, this is because "this" is a keyword, and * therefore invalid as an identifier.</li> * <li>An expression with "super" can only be represented as a super field * access expression (<code>SuperFieldAccess</code>). "super" is a also * keyword, and therefore invalid as an identifier.</li> * <li>An expression like "foo.bar" can be represented either as a * qualified name (<code>QualifiedName</code>) or as a field access * expression (<code>FieldAccess</code>) containing simple names. Either * is acceptable, and there is no way to choose between them without * information about what the names resolve to * (<code>AST.parseCompilationUnit</code> may return either).</li> * <li>Other expressions ending in an identifier, such as "foo().bar" can * only be represented as field access expressions * (<code>FieldAccess</code>).</li> * </ul> Also added pointers from QualfiedName, SuperFieldAccess, and ThisExpression. Changes released to HEAD stream.
Verified.
