On Sat, Aug 5, 2017 at 11:05 AM, Naveen Chawla <[email protected]> wrote: > > Does existing code use modules??? My understanding is that > modules are a recent concept.
Yes, people have been using ES2015-style modules for a couple of years now (obviously, modules in general much longer than that), via transpilers and bundlers, and recently with some initial native implementations (Chrome v60 has it behind a flag, I think v61 will have it by default; I believe there's a Safari tech preview). But I mostly meant code in general (and/or which is bundled up in a module at some point), not module-specific code. > And the `module` keyword would only apply in actual modules I imagine that's possible. In general, something that's an identifier in some code but a keyword in other code doesn't sound like a good idea to me. But there's something *like* a precedent: Until ES5, you couldn't use a keyword as a literal property name (e.g., in a property accessor -- `element.class` and `element.for` were famously syntax errors, leading to the DOM using `className` and `htmlFor` instead); as of ES5, you can, because the context is sufficiently clear that the accessor and object initializer productions could use *IdentifierName* rather than *Identifier*. Your concept goes further, making the *same production* parse as a keyword in *ModuleBody* code but an identifier in *ScriptBody* code. These issues don't exist with `import`, which has been a "future" reserved word for 20 years. So while `module` may be *slightly* more semantically obvious, I think you'll struggle to get people on-board with the complexity of adding a context-sensitive keyword. -- T.J. Crowder
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
