ECMA TC 39 / W3C HTML and WebApps WG coordination
1981km at gmail.com
Fri Sep 25 15:34:00 PDT 2009
>> Do we need a WindowProxy in the core language? I'm not sure, but if
>> not then there has to be some other way of specifying how |this| in
>> global code binds to the outer window rather than the inner (Ecma
>> global). We didn't try to make something up here for ES5.
> ECMAScript could just allow host embeddings to make the outermost
> scope chain entry be something other than the global object. The main
> downside is that this is more loose than is needed and could
> technically allow crazy unreasonable things. But it may not be
> possible to fully specify the behavior at the ECMAScript level, since
> it depends on the notion of navigation. There may be a way to provide
> a more narrowly tailored hook.
ECMA-262 allows (in 15.1) the prototype of the global object to be anything (including a host object with catchall semantics, or with properties existing for all names, just with value undefined, custom [[Put]] and [[Get]], etc.). Would implementing WindowProxy on that object and Window on the global object solve the use cases?
Is there actually a comprehensive list of use cases for this splitting anywhere, to facilitate checking any potential solutions against them?
More information about the es-discuss