Tree API: offsets for String fields

[Sundararajan Athijegannathan]

Filed: https://bugs.openjdk.java.net/browse/JDK-8156866

PS. Actually, I was wrong about MemberSelectTree - even internally
nashorn IR node "AccessNode" maintains 'property' as a String. But,
variables, functions have identifier nodes for names.

Thanks,

-Sundar


On 5/12/2016 10:20 PM, Emilian Bold wrote:
> Assuming I don't need some special permissions to do that (do I?) I
> could expand the previous email and post it as an enhancement
> on https://bugs.openjdk.java.net
>
> But I'm also trying to understand the logic behind what you have.
>
> The way I see it any AST node has some underlying tokens so its
> offsets should be based on that.
>
> Take VariableTree. The Javadoc mentions:
>
> var name initializer ;
>
> but I assume the offset ranges are something like
>
> var [name = [initializer]] ;
>
> So, 'var' and whatever whitespace there is in between is ignored. The
> 'name' offsets are not explicit but may be inferred.
>
> (A similar problem with FunctionDeclarationTree.)
>
> What I would do with Variable Tree would be to have the offset ranges
> like:
>
> [var [name] = [initializer]]
>
> with the VariableTree covering everything ('var' too) and 'name'
> having a separate IdentifierTree.
>
> Continue/BreakTree/LabeledStatementTree are not really that
> important/used so if there is no internal info it's no big loss.
>
> --emi
>
>
> On Thu, May 12, 2016 at 7:19 PM, Sundararajan Athijegannathan
> <sundararajan.athijegannathan at oracle.com
> <mailto:sundararajan.athijegannathan at oracle.com>> wrote:
>
>     Hi,
>
>     Thanks for your comments. Nashorn Parser API was modeled after similar
>     API provided by javac - for consistency sake and to leverage developer
>     familiarity.  For example, ContinueTree, MemberSelectTree of javac
>     Tree API:
>
>     https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/ContinueTree.html
>
>     https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/MemberSelectTree.html
>
>     I agree that consistency should not result in API 'mistakes/gaps'
>     being
>     propagated here.  BTW, labels are maintained as strings even
>     internally.  Member select property, Variable name , Function name
>     etc.
>     are all identifiers and so it is possible to make API return
>     IdentifierTree objects. Will you please collect whatever you found and
>     file a bug/enhancement for Nashorn parser API?
>
>     Thanks,
>
>     -Sundar
>
>
>     On 5/12/2016 9:10 PM, Emilian Bold wrote:
>     > Hello,
>     >
>     > It's really important for a Javascript editor to know the
>     offsets of each
>     > syntax tree node and of whatever the node contains (I'm not
>     really saying
>     > tokens but... constituent parts and keywords are the minimum).
>     >
>     > So it would be great to provide or document how offsets are to
>     be computed
>     > for the String fields from the Nashorn Tree API.
>     >
>     > (Ideally the API could also be changed to use an IdentifierTree
>     or some
>     > other Tree subclass which provides the start/endPosition.)
>     >
>     > A few examples:
>     >
>     > * MemberSelectTree has a String getIdentifier. Since I *assume*
>     that the
>     > MemberSelectTree.getEndPosition is right after the identifier, I
>     have to
>     > subtract the identifier length to get the identifier start offset.
>     >
>     > * VariableTree has a String getName(). It seems to me that
>     > VariableTree.getStartPosition is the 'name' startPosition. This
>     also means
>     > you cannot really know where 'var' actually is -- it could be on
>     another
>     > line altogether; it's also odd to me that 'var' is outside the
>     [start, end]
>     > range for the VariableTree.
>     >
>     > * ContinueTree and BreakTree both have a String getLabel
>     >
>     > * LabeledStatementTree has a String getLabel
>     >
>     > * FunctionExpressionTree and FunctionDeclarationTree both have a
>     String
>     > getName but I'm not sure how the offset for that is computed.
>     Also not sure
>     > how the offset of the 'function' keyword would be computed.
>     >
>     > Could somebody explain this to me? I'll make a nice list for future
>     > reference.
>     >
>     > --emi
>
>