The global object in browsers
brendan at mozilla.com
Tue Feb 17 21:20:23 PST 2009
On Feb 17, 2009, at 8:17 PM, Mark Miller wrote:
> On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich <brendan at mozilla.com>
> 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
> 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
> As for performance, wouldn't a shallow binding implementation
> make switching which page is current be more expensive, but variable
> access within a page, even after a switch, would have no added
>  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
> 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
This doesn't work for security or performance.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss