On Sep 25, 2009, at 3:34 PM, Krzysztof Maczyński wrote:
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.
Regards,
Maciej
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?
ECMAScript requires the outermost scope chain entry and the object
that is used as "this" for global function calls to be the same
object. But the scope chain entry cannot be directly observed, so the
only observable difference is in property access behavior. Nothing
requires this to be stable and consistent for a host object.
But ECMAScript doesn't have a way to distinguish normal property
access from property access via lexical scoping. It's unclear whether
you could say an object is actually "the same" but happens to give
different answers for scope chain access and direct property access,
and possibly even different answers depending on which scope chain it
was found in. I would think that strains host object exemptions to the
breaking point.
Regards,
Maciej
