RFR 8134941: Implement ES6 template literal support
andreas.woess at oracle.com
Fri Nov 6 14:33:42 UTC 2015
thanks for your reviews and sorry for the late reply.
>> Template literals are always scanned as a whole, quote-to-quote (as
>> with EditStringLexer). This turned out to be a problem with embedded
>> functions in expressions and lazy/optimistic compilation on:
>> Parser#skipFunctionBody would skip over the body and restart lexing
>> at the RBRACE, forgetting about the embedding string context. I've
>> worked around this in skipFunctionBody by skipping over to the RBRACE
>> directly if it is already in the token stream (which it is because
>> we've already scanned to the end quote).
> It took me some time to figure this out. Maybe some more explanatory
> comments would be good. Does this also apply in other cases?
From the top of my head I'd say no, because we don't start the lexer at
arbitrary positions, but only at a brace, and no other case comes to
mind where we could end up with different tokens here. Yes, some more
comments wouldn't have hurt. :)
It would probably be good to use the same code for scripting-mode `exec
strings` which still have this and the quoting issue I mentioned.
> We can probably file the issues as separate bugs and fix them later.
> One thing I want to do is add some more tests. Although your test
> script covers a lot of stuff (for its size) I would like to add a bit
> to it.
Regarding caching of template objects: yes, we should follow the spec
here, I deliberately left that out because I wanted to focus on the
> I’m sometimes in two minds about RuntimeNode (especially the fact that it currently can’t receive primitive parameters), but I have to admit that in this particular case it made the integration of the feature into the runtime fairly easy; it was really the parser parts that were tricky.
Yes, I like how simple it was to add runtime support with this approach,
but you can certainly do better. Originally, I thought about adding
another LiteralNode, but it would've been unnecessary complexity.
More information about the nashorn-dev