Perhaps this would be a good initial W3C HTML WG/ECMA TC-39 joint work item if we can expeditiously get past the bureaucratic hurdles. The fact that there isn't an existing consensus behavior among the major browsers would seem to present an opportunity to step back a bit and take a new look at the problem.
My sense, is that there are issues that go deeper here simply the binding of the ECMAScript global object to a browser Window object. It's really about providing a clear definition of the execution environments for scripts (and potentially other code) within browsers and how such execution environments are associated with browser abstractions such as windows, pages, frames, etc. In particular, what are the life times of such execution environments and when are direct object references required/permitted/forbidden to be shared between them. Also when are proxy references required/permitted/forbidden and what are the characteristics of such proxies. I don't think we should wait to address these issues as part of the larger ES-Harmony effort As I've previously mentioned I think from an ES perspective it could be initially addressed in an ECMA Tech Report that describes how the single ES global environment should map into the browser execution context. I think the most important point is that these issues should be addressed from a holistic browser perspective rather than just from a ES or HTML perspective. Allen From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Tuesday, February 17, 2009 3:17 PM To: Mark Miller; Ian Hickson Cc: es-discuss Steen Subject: Re: The global object in browsers On Feb 17, 2009, at 3:09 PM, Brendan Eich wrote: On Feb 17, 2009, at 2:48 PM, Mark Miller wrote: On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson <i...@hixie.ch<mailto:i...@hixie.ch>> wrote: Now, if the other page's script calls f() and g(), it will get different results (2 and 1 respectively, if I didn't screw up the example code). For HTML5, this behaviour has been defined in more detail. The global object is a Window object. This object is per-Document. The object returned by the "window" attribute on that global object is actually a WindowProxy object, which forwards everything to the "current" Window object. What do you mean by "current"? Are you proposing to legitimize the dynamic scoping behavior demonstrated by your example? What Ian showed is not dynamic scoping. var global = this; function g() { return global.x; } The issue is what global.x means after the current page (the one containing the script including these two lines) has been unloaded and a new page loaded (while some other window keeps a reference to g). The call to g comes from another window, and it would be dynamic scoping if that window were the global object for the activation of g. It's not. The other window is nowhere on the scope chain. The only issue is whether the proxy forwards to the inner in which g was bound, or the current inner. Finding the inner in which g was bound from the proxy is not feasible in general. But we could find g's statically linked scope parent ([[Scope]] in ES3), which would be the inner in which g was defined. I raised this idea on IRC recently, and Hixie replied that the proxy (denoted by global) might have no relation to g's [[Scope]]. But that could in theory be handled, I think, by comparing the proxy to which global was bound to the proxy for g's [[Scope]] (inners keep track fo their outer, that is easy; the reverse is 1:N and not easy). If the same proxy is associated with g's [[Scope]] as is the base of the reference being evaluated in g, then use g's [[Scope]]. Else use the current inner global for the proxy. This could be done, but it would add a kind of alias checking to all property accesses. And it's not what any browser does. So it's probably right out, but I wanted to raise it in detail. /be
_______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
