import.meta and TC39 process as a whole
Dmitrii Dimandt
dmitrii at dmitriid.com
Sat Aug 5 16:05:31 UTC 2017
Languages *evolve*. It means that at some point something will be introduced that may break existing user code.
I understand that with JS the problem is compounded a billion-fold (JS is used quite literally everywhere).
However: Looking at the evolution of JS we can see that new entities and new assumptions (potentially breaking user code) are continuously added to and removed from JS (as they should).
So, in my opinion, the argument for not adding new global entities such as System, or Module, or Loader (or heck, even all three of them) being “these are not keywords, we can’t introduce them” is really really weak.
On Sat, 05 Aug 2017 at 12:45 "T.J. Crowder"
<
mailto:
> wrote:
a, pre, code, a:link, body { word-wrap: break-word !important; }
On Sat, Aug 5, 2017 at 11:05 AM, Naveen Chawla
<
mailto:naveen.chwl at gmail.com
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170805/68f38410/attachment.html>
More information about the es-discuss
mailing list