On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
> 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. > Now here is a reason, finally, for all the extra complexity the two goals cause. If we want to kill script, let's not stab it with a dull pencil. Let's make Loader and System be modules, not globals. Then you cannot load modules with <script>, only with <module>. > > > 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss