On 4 May 2012 06:42, Allen Wirfs-Brock <[email protected]> wrote: > 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
Sounds reasonable, although the latter points are certainly debatable. > 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. I understand the role of the GO and the TL, but what is the function of a separate built-ins environment? That is, where and how can it be observed (in a browser or stand-alone environment)? In the module API? > 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 Hm, how does making it "configurable" fit in with the 1JS tale? Even if the configuration is pre-selected by external means, it still means that JS-in-the-browser is effectively a different language than JS-standalone. In any case, I still think we should strive to make the global scope as coherent with module scopes as possible. That is, the global scope itself should be as "module-like" as possible. From that point of view, it makes perfect sense to keep the global object as a reification of the toplevel lexical scope (including new binding forms), analogous to module instance objects reifying module scopes. I believe that makes for a more consistent (and more compatible) language than introducing schisms between old vs new built-ins, old vs new declaration forms, and toplevel vs module scopes. Is there any particular reason why you think this is not desirable? What is e.g. the gain of not reflecting new declarations on the global object? /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
