On 3/12/14 2:40 PM, Brian Slesinsky wrote:
> Interesting. I think the sticky part will be providing the
> getLocals(), getDisplayValue(), and eval() functions. I think it's
> by the compiler, since this allows a lot of flexibility. But which
> 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.
I was imagining it would run in the frame the debugger was paused in.
Perhaps I am missing something, but if you are already running a site's
code, why would they need to send the bad stuff via the debugging
It should still respect CORS, though.
Furthermore, using the debugging information should always be optional.
> Another issue is discovering the language-specific runtime type
> structures, 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 there too.
> How to discover the runtime type will be language-specific, and
> furthermore, the value stored in the variable may come from a
> different language. For example, GWT allows passing both Java and
> 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.
Sure. This is a perfect example of why I focused on an extensible format
-- so we can add annotations that we initially overlooked, and fix
mistakes post facto.