debugging interfaces

Mark S. Miller erights at
Tue Jun 16 09:27:32 PDT 2009

On Tue, Jun 16, 2009 at 7:18 AM, Jordan Osete <jor at> wrote:

> After a quick look into this PDF (very instructive, thanks), I think I
> understand the advantages of having a mirror API that is clearly distinct
> from the rest of the ES API.
> However, ES already has a number of reflection features built in, that are
> clearly not stratified. From the prototype and constructor property,
> statements that allow to list properties, typeof, instanceof,
> including new ones like the functions to __define / __lookup a Getter__ /
> Setter__,

Yes, JavaScript is already pervasively reflective in a non-stratified way.
However, none of these violate the encapsulation of the one and only
encapsulation mechanism present in EcmaScript -- functions evaluating to
lexical closure that capture the variables in their scope. All the new
reflective operators introduced by ES5 were careful to respect this boundary
as well. De-facto JavaScript does have further reflective operators that do
violate encapsulation -- <function-instance>.caller,
<function-instance>.arguments, arguments.caller, and arguments.callee. ES5
specifies that these be disabled for strict functions so that the
encapsulation of strict functions remains defensible.

> including the actual stack traces API (like the Mozilla Stack object
> ).

This does violate information encapsulation and so does threaten
confidentiality. However, it provides no access and so does not threaten

> Also, there are a variety of environments a JS "thread" can run in today.
> For browsers, it may run in an HTML page, or in a Web worker, but it may
> also run in a command-line interpreter, and even as a server-side language.
> Will all those need different ways to get JS threads for examination ?
> As for the browser, for example (sorry, it is by far the environment I am
> most familiar with), I think it would be nice to still allow a page to
> access this mirror API to "explore" another page, without needing explicit
> user consent under certain conditions (like a same-origin policy for the
> inspector / inspected page, for example). Test suites come to mind.
> Would this kind of things be acceptable, from a security point of view ?

Not by itself, no.

> It *seems* Opera Dragonfly is using some kind of "Scope" thing as its
> mirror / proxy API (
>, and
> then the rest is pure web (Opera developers' insight would be welcome on
> that matter).
> However (still about the browser), even the proxy part can be moved to pure
> web technologies (like XHR, through some server), in a debugging lib. That
> would leave only the mirror API to define in the standard.

Will take a look. Thanks for the pointer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list