Summary: | JDT ASTs: QualifiedName versus FieldAccess | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Timothy Halloran <hallorant> |
Component: | Core | Assignee: | Jim des Rivieres <jeem> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | akiezun, dirk_baeumer, jeem |
Version: | 2.0 | ||
Target Milestone: | 2.1 M1 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Timothy Halloran
2002-08-02 14:03:51 EDT
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. |