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