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?
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?
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.
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.
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
