Interesting. I think the sticky part will be providing the getLocals(),
getDisplayValue(), and eval() functions. I think it's right that they
they run in and what do they have access to? I think it would have to be a
sandbox of some sort and there may be security implications for curious
developers who run untrusted code with the debugger window open.
Another issue is discovering the language-specific runtime type associated
knowing the AST node for a local variable may not provide much help. For
example, in Java, you may have a variable with a static type of Object and
the runtime type could be anything. You also might want to look at globals
from the console, and language-specific variable inspectors would be useful
How to discover the runtime type will be language-specific, and
furthermore, the value stored in the variable may come from a different
back and forth. So I think we will need a way to ask each language if it
wishes to "claim" an object and provide the variable inspector for that
object. Probably the language associated with the AST node goes first, but
if it doesn't know what it is, the other languages should be queried.
On Wed, Mar 12, 2014 at 2:04 PM, Fitzgerald, Nick
> There has been a little bit of talk on es-discuss about properly
> standardizing source maps for inclusion in ES7. My reply outgrew an
> email response, and so I collected my thoughts here:
> It is probably of interest to this group as well, so I'm linking it here.
> dev-js-sourcemap mailing list