Thank you! PS: It would be great if JBS would allow me to register for email updates on issues I care about...
--emi On Thu, May 12, 2016 at 8:10 PM, Sundararajan Athijegannathan < sundararajan.athijegannat...@oracle.com> wrote: > 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.athijegannat...@oracle.com> > sundararajan.athijegannat...@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 >> >> > >
