On Feb 17, 2009, at 8:17 PM, Mark Miller wrote:
On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich <bren...@mozilla.com>
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
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
