Community
Participate
Working Groups
there seems to be now easy way to compute the location of the 'super' keyword in the 3 nodes below: SuperFieldAccess SuperMethodInvocation SuperConstructorInvocation
i need location and length (it can vary between locales i think (?))
Jim - Any comment? Even if the 'super' keyword is implicit, we might want to get its positions.
same is true for 'this' in ThisExpression, the Operator in InfixExpression the Operator in PrefixExpression the Operator in PostfixExpression the 'class' keyword in TypeLiteral and so on ... - the problem is more general for now - _i_ only need 'super' though but all of the above will be asked for at some point
The source coordinates of the 'super' keyword (and other keywords as well) are not explicitly stored. Additional source coordinates should be obtained by explicitly scanning. For example, for a SuperFieldAccess with the qualifier non-null, the tokens ".", "super", and "." (plus arbitrary whitespace and comments) can be expected to lie between the end of the qualifier and the start of the name.
fair enough - the scanner is not api yet, though :) ok to close
I agree that we should use the scanner for those extra positions since otherwise we end up having positions for every single token. Two things: - when will the scanner be API - do you think it is of any use if the AST provides API to access a scanner ?
I am considering surfacing the scanner as well, but it is somewhat tricky given it is currently holding onto internal stuff as well. It is on the plan for 2.0, see bug 3354
Scanner API will be surfaced in next integration build. Ok to close this one then ?
yes, thanks
The issue is about surfacing the scanner API and not providing new positions inside the existing DOM/AST nodes. The scanner API will be surfaced next integration build, so we can close this one. Closed.
