import script --> .esm
matthewwrobb at gmail.com
Wed Sep 10 11:23:27 PDT 2014
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:
> On Sep 10, 2014, at 2:13 PM, "Matthew Robb" <matthewwrobb at gmail.com>
> 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>
>> On Wed, Sep 10, 2014 at 10:40 AM, Matthew Robb <matthewwrobb at gmail.com>
>>> 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 (
>> sense. Modules (
>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-modules) are
>>> 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.
>>> 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
>>> - Matthew Robb
>>> On Wed, Sep 10, 2014 at 1:33 PM, Brendan Eich <brendan at mozilla.org>
>>>> 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
>>>> Tools will have to read metadata, tea-leaves, and etheric winds to keep
>>>> up. Same as ever.
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss