I should have also included: 2A) Hopefully, overtime, the old script syntactic goal will fade from use, and the module goal will become the norm for new code.
On Jan 24, 2014, at 11:38 AM, Allen Wirfs-Brock wrote: > > On Jan 24, 2014, at 9:32 AM, David Bruant wrote: > >> Le 24/01/2014 18:26, John Lenz a écrit : >>> >>> >>> REPL is a dilemma: if you parse as module, then obtaining the last >>> expression value is not simple. if you parse as a script, then common >>> cut/paste fails on export/import statements. >>> >>> My basic question remains. As a tool owner how do I know if what I'm >>> looking at is intended to be a Module or a Script? >> How do you know if some code is intended for the browser or Node? >> How do you know some code is intended to be used in a WebWorker and not in >> the main thread? >> How do you know the code won't be concatenated a "use strict" when someone >> else uses it? >> >> The code itself lacks the context in which it's being loaded (hence very >> defensive patterns like UMD (Universal Module Definition)). >> If you want to be exhaustive, you'll have to make an assumption or make your >> tool smarter about the context. > > I've had some discussion with Dave Herman about this and I think there is a > plausible way to handle it. I'm not sure if Dave would totally agree with > 100% of the following but I think it is close to what seemed to make sense > in our discussions. > > 1) there are some very good technical reasons for having two syntactic goals > (script and module) corresponding to the two semantics. > > 2) A module with no imports and no exports is essentially a new form of top > level code that is always strict mode and but has its own "file level" scope. > > 3) In browsers, html syntax (new attribute on script tag, etc.) can be used > to distinguish the two. Dave is working on this. > > 4) but there are other situations where the intended syntactic goal of a > source file need to be identifiable. For example, when listing source files > on a command-line invocations of a JavaScript engine or tool > > 5) Humans when reading or managing code files also need to know which kind of > JS source file they are dealing with. > > 6) typically we use file extensions to make distinctions of this sort. > > 7) Hence, it probably makes sense to promote a convention of using a new file > extension for ES6 source files that are intended to be parsed with the > modules goal. .jsm, or mjs, or something similar that is appropriately > suggestive and isn't already widely used as an extension. > > Allen > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
