The global object in browsers

Mark Miller erights at
Tue Feb 17 23:18:38 PST 2009

You misunderstood me a bit, but no matter. Now that I better understand the
constraints -- thanks! -- what I was trying to say is irrelevant. What I
mess. I am at a loss to find anything sensible to recommend.

On Tue, Feb 17, 2009 at 9:20 PM, Brendan Eich <brendan at> wrote:

> On Feb 17, 2009, at 8:17 PM, Mark Miller wrote:
> On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich <brendan at> wrote:
>> On Feb 17, 2009, at 6:31 PM, Mark Miller wrote:
>>  Now that I think I understand "current" and how weak the legacy
>>> constraints are, why not simply spec that your WindowProxy is the object to
>>> treated as the ECMAScript global object? The consequence would be that both
>>> f() and g() in your original example would return 2.
>> That either opens a huge security hole, or imposes costly runtime checks
>> on all lexical references to global variables.
> If Ian's Window object were provided as the ES global, then we'd have the
> security problem you're concerned about. But, IIUC, with the WindowProxy we
> don't.
> That seems half-right. The ES global at the end of scope chains is the
> "inner" Window object. The perisistent-identity global that you get your
> hands on via the DOM, |this|, |self|, and |window| is the "outer" or
> WindowProxy object.
> Which one did you mean by "the ES global" in the first sentence cited
> above?
> As for performance, wouldn't a shallow binding implementation[1] make
> switching which page is current be more expensive, but variable access
> within a page, even after a switch, would have no added expense?
> [1] The two primary methods of implementing dynamic scoping were known as
> "shallow binding" and "deep binding". Although "current" is not dynamic
> scope, some of the same issues and tradeoffs apply.
> You are missing the requirement that the identity of the "outer"
> WindowProxy, which contains a series of documents loaded into it over time,
> remain the same, while the identities, plural, of the "inner" Window
> objects, each the global for its own document, also remain the same.
> In a shallow bound implementation. the WindowProxy's properties are direct
> properties -- not forwarded. On page navigation, these properties are copied
> into the Window object corresponding to the old page, and the properties on
> the Window object corresponding to the new page are copied onto the
> WindowProxy.
> And the scope chains for all the functions and activations in the old page
> are rewritten to refer to the Window object corresponding to the old page,
> not the WindowProxy? This does not scale at all.
> And the reference monitor that checks access rights in the WindowProxy must
> run when the accesses come from only certain code. How does that work
> without disjoint global (end of scope chain) objects but persistent |this|?
> You can't know to skip the check and avoid a bad performance hit. The
> lexical references must suffer no penalty.
> Another analogy is with the register store in thread control blocks in an
> OS implementation. One can describe the semantics of computation in a given
> OS as directly updating the "current" per-thread register set. But instead
> of paying the indirection on register access, we'd rather pay the copying
> overhead on context switch.
> This doesn't work for security or performance.
> /be

Text by me above is hereby placed in the public domain

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

More information about the Es-discuss mailing list