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