The global object should not be the "global scope instance object"
brendan at mozilla.org
Fri Jan 27 14:35:29 PST 2012
> Andreas Rossberg <mailto:rossberg at google.com>
> January 27, 2012 12:06 AM
> On 26 January 2012 20:51, Brendan Eich<brendan at mozilla.org> wrote:
>> Andreas Rossberg<mailto:rossberg at google.com>
>>> I still like the idea of cross-script shadowing (aka nested scopes),
>>> but one concern was that it is not clear what names would be in scope
>>> for, say, a piece of JS code in a random HTML attribute somewhere on
>>> the page.
>> We could say event handler attributes are scoped by the most-nested scope --
>> the scope due to the last<script> element that was closed before the
>> element with the event handler attribute was processed.
> Why not the last (most-nested on page) scope?
Because event handlers on elements are interspersed with scripts and so
far, order matters. An event handler might run when later scripts have
not yet loaded. Progressive rendering and even event handling are part
of the relied-upon processing model.
>> But it's worse than that. What about<script async src="..."> (or the
>> HTML4-era, not fully supported on all browsers<scriptdefer src="...">?
>> Async scripts are not supposed to have global effects other than defining
>> functions that the page or app author ensures won't be called till after all
>> content (or at least all scripts, or at least all of the needed async
>> scripts) has finished loading. In what scope do async script let/const
>> top-level bindings go?
> I suppose they'd nest in the order they get loaded. There is no
> escaping the fact that you'd still have a stateful notion of "current
> toplevel scope" on a page that affects the meaning of later scripts,
> attributes and such. But at worst later scripts can shadow bindings
> from earlier ones, which does not accidentally affect those earlier
> ones. Compare with the situation today, where later scripts may modify
> the meaning of previous ones by accidentally overwriting their
Sure -- that is used in some cases, perhaps for want of better
mechanism, but not for want of shadowing.
> If you don't want to forbid multiple bindings across script
> altogether (Allen's proposal), then what other alternative is
<script>-level let and const are local to that particular script element.
More information about the es-discuss