import script --> .esm

L2L 2L emanuelallen at hotmail.com
Wed Sep 10 17:23:00 PDT 2014


.... So... Your saying bring environmental scope to the script file... As having it's own context execution... Like each script tag is its own iframe or DOM environment, while in the same html page?

E-S4L
N-S4L

> On Sep 10, 2014, at 2:24 PM, "Matthew Robb" <matthewwrobb at gmail.com> wrote:
> 
> I don't think it should have anything to do with modules though. It's a fundamental change in the scoping/execution mechanics of any new script compiled into a running environment. Previously new code compiled and run would execute with global scope and sloppy mode. My suggestion is a pragma you COULD put at the top of script and if present that script will be compiled and run in the environment using the new scoping/execution mechanics of implicit strict mode and local-global scoping. Then the spec would simply state that modules are not compatible with the legacy mode and implementations should position the new mode as default some how. (file extension or what have you)
> 
> 
> - Matthew Robb
> 
>> On Wed, Sep 10, 2014 at 2:16 PM, L2L 2L <emanuelallen at hotmail.com> wrote:
>> 
>> 
>> E-S4L
>> N-S4L
>> 
>>> On Sep 10, 2014, at 2:13 PM, "Matthew Robb" <matthewwrobb at gmail.com> wrote:
>>> 
>>> But if the goal is for everything going forward to use the scope environment characteristics of modules (strict-mode and local-global) then why not specify that and move the old model to a legacy mode. This just shifts all existing implementations to be compliant with legacy mode but not yet compliant with the new mode. This should be fine it's mostly about how to view and focus efforts when writing the spec, adding features, using new features, and teaching the language.
>>> 
>>> 
>>> - Matthew Robb
>>> 
>>>> On Wed, Sep 10, 2014 at 2:05 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
>>>> 
>>>> 
>>>>> On Wed, Sep 10, 2014 at 10:40 AM, Matthew Robb <matthewwrobb at gmail.com> wrote:
>>>>> I just think the idea of 1JS has already been compromised and really what we have is a spec that supports two almost-entirely different sets of expectations. The maintenance of keeping them of equal priority seems like it will only get worse over time. The `"use strict"` pragma is already sort of an opt-in to the new mode.
>>>> 
>>>> Only in non-strict Script (https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-scripts-and-modules) sense. Modules (https://people.mozilla.org/~jorendorff/es6-draft.html#sec-modules) are strict-by-default.
>>>>  
>>>>> To me the more graceful path forward is the one where the world as people know it stays the same but then there is an opt-in path for moving to the supersets of the future.
>> 
>> Yes!... If your saying do something similar as " use strict"; for module. Like "use module"; than yes I agree with this.  
>>>> 
>>>> Unnecessary when nothing about the future directly changes the extant works of the past. 
>>>> 
>>>> 
>>>> Rick
>>>>  
>>>>> Dong this once after having considered many of the issues of the old model seems reasonable to me specially with the amount of buy in people are doing on transpilers and even buy in on other languages/runtimes such as dart.
>>>>> 
>>>>> 
>>>>> 
>>>>> - Matthew Robb
>>>>> 
>>>>>> On Wed, Sep 10, 2014 at 1:33 PM, Brendan Eich <brendan at mozilla.org> wrote:
>>>>>> Matthew Robb wrote:
>>>>>>> I don't see why they have to? Traceur should be used as a build time tool that ultimately runs in legacy mode. Only REAL modern ES6 module implementations would run in this other world. Basically .es files today would be transpiled into .js files.
>>>>>> 
>>>>>> I doubt people will do any such thing. We can have more suffixes (I was against .js2 in particular -- that particularly confusing proposal was why I unleashed the Nope-topus), but if people can adapt their existing practices with AMD/Require/CommonJS modules and use just .js, I bet they will.
>>>>>> 
>>>>>> Tools will have to read metadata, tea-leaves, and etheric winds to keep up. Same as ever.
>>>>>> 
>>>>>> /be
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/939c4ac3/attachment-0001.html>


More information about the es-discuss mailing list