On May 4, 2012, at 8:33 AM, David Bruant wrote: > Hi, > > Le 04/05/2012 06:42, Allen Wirfs-Brock a écrit : >> Goals: >> Duplicate current browser global semantics >> Existing ES5 built-ins are properties of "the global object" >> Global Function and Var declarations create properties of the >> global object >> Ad hoc semantics relating explicit Function/Var global bindings and >> non-declared global object properties include attribute and inheritance >> issues >> Don't make the web compatible global object worse >> New declaration forms (let/const/class) shouldn't pollute the >> global object >> Don't add any new ES built-in bindings to the global object >> Don't force non-browser or nested ECMAScript global environment hosts to >> duplicate quirky browser global semantics > What are "nested ECMAScript global environment hosts"? Can you provide an > example? Is what has been done with the Firefox WebConsole (and how it > interacts with a page) such an example?
The sort of nested top-level environments that can be created using Module Loaders http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders (but they aren't "modules" or "loaders"). The working term I'm using as I rough out spec. language is "Realm" but the terminology is certainly open for discussion. > > I don't understand this last goal regarding non-browser environments. As an > example, Node.js got away from the shared global declarations mess by > defining a module system (where global declarations of each module is local > to the module). ES6 is defining a module system with an equivalent design. > Moving forward, why would an ES6-compilant non-browser environment have > different rules than the standard one for modules? Are there use cases that > can't be fulfilled with custom module loaders? What I'm talking about, is the specification that lies behind what you can do with a custom module loader. It is essentially the interface between global declaration semantics of the language and what module loaders can configure. I'm also not talking about the top-level inside a module, I'm talking about the top level of ES Program productions and in particular the relationship between the global object and Program top-level declarations. The sort of "quirk" that I don't think needs to be (mandatorily) forced upon non-browser top-levels includes things like treating placing top-level var/function declarations into a different environment contour (the global object) from the new lexical declaration (const/let etc.). Polluting a top-levels global object with declaration bindings or built-in bindings, or even requiring a top level to have a global object. > >> Basic Approach >> Define a global environment model that is flexible enough to both >> maintain compat. with existing browser semantics and allow simpler >> non-browser global semantics >> >> Three sub-environment of the global environment record: >> Built-ins: declarative environment record , immutable bindings for >> standard and impl defined built-in globals >> Global Object: A Object environment record, that shadows the >> built-ins. Content is host defined and may replicate global bindings for >> globals >> Top Lex: A declarative environment record that shadows the Global >> Object environment for lexical bindings created by top level declarations >> >> These sub-environments are hidden behind the environment record interface of >> a single global environment record, hence their existence does not impact >> the rest of the specification. >> When a global environment is initialized it can be configured so var and >> function declaration bindings go into either the Global Object environment >> or the Top Lex environment >> >> The structuring of Top Lex to support declarations from multiple >> program/script fragments is an orthogonal issue. However, I favor a single >> top lex shared by all program/script fragments. > If they all share the top lex, the issue that came with web browsers > (overlapping global declaration) remains exactly as it is. Is it what you > meant? > I would naively be more in favor of one top lex per program/script fragments > to avoid to inadvertidly share global declaration of each program. How to handle the declaration interactions between Programs/scripts was extensively discussed on the threat https://mail.mozilla.org/pipermail/es-discuss/2012-January/019807.html. I think we are going to end up going with the STL (Single Top Level) solution. This is a decision that we need to finalize at the next TC39 meeting. However, browser compatibility requires that var/function declarations create global object properties. That is why the structure of top lex is an orthogonal issue. > >> >> Common ways to configure the global environment: >> >> Browser compat: >> ES5 built-in global bindings replicated on the global object >> any new ES6 built-in global bindings are not replicated on the global >> object > I disagree with this point as it makes web browsers inconsistent. Some code > does feature detection by testing presence on the global object (since it's > currently equivalent to "typeof builtinGlobalName !== 'undefined'"). You're > saying that the equivalent should be broken, so, ES5 and ES6 features won't > be feature-detectable the same way. > I don't think there is a loss in having ES6 built-in global bindings > replicated on the global object. Actually, Firefox does define WeakMap and > Map as global object properties. "typeof builtinGlobalName" doesn't change in anything I proposing here. From the perspective of ES code and identifier resolution there is simply a single global lexical contour that includes all built-ins, top-level declarations, and properties of the global object. The "sub-environments" I'm talking about is simply a means to define the interactions between language induced bindings and properties of the global object (if there is one). It isn't at all clear to me why WeakMap, Map, or any other future ES global binding should be polluting the property name space of the DOM window object. Why is referencing window.WeakMap a good idea? > >> global var/function declarations create bindings on global object >> environment >> global const/let/class/module declarations create bindings in Top Lex >> This would be specified in the browser specific optional/normative >> annex. >> >> Clean Global Object >> No built-ins replicated on global object >> all ES top level declarations (including var/function) create >> binding in Top Lex >> global object properties are only be created via explicit reference >> to global this >> >> No Global Object >> Global object is undefined >> all ES top level declarations (including var/function) create binding >> in Top Lex >> Thoughts? I'm ready to write the spec for this. > I think it's a very important work. As far as I know, ECMAScript 5 and below > did not define anything regarding what happens when several programs > interact. We all know how it works in browsers, but I don't think it's > specified anywhere neither in ECMAScript, WebIDL or HTML Living Standard. > Especially with modules coming along, I think it's important this topic to be > standardized at the ECMAScript level. The nomenclature you're defining may > actually need to be reused in custom module loaders. > > David >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
