Rationale for dropping ModuleImport syntax?

[John Barton]

If the 'module' form is left out, it can be added later. If the 'module'
form is left in, it can never be removed.
jjb


On Mon, Jun 9, 2014 at 6:39 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

> Isn't the problem, though, that default-exporting an object prevents
> static checking? It feels like an abuse of this feature to me.
>
>
> We don't have static checking today, so this is no loss to me.
>
>
> If I understand ES6 modules correctly, importing a non-exported identifier
> gives you a load-time error (that’s what I meant with “static checking”).
> If you default-import an object with exports, you only get run-time errors.
>
> This is more subjective, but what I like about modules is that they lead
> us away from objects-as-modules. If default exports, used in this manner,
> become popular, that won’t really happen. We’ll have pseudo-modules, used
> inside a module system.
>
> (And ES6 modules give enough benefits over ES5 ones without static
> checking to still have a chance in the marketplace, e.g. they statically
> require imports being at top-level and string-only, and automatically
> introduce `"use strict"` for you.)
>
>
> I agree. I also love tools such as the es6-module-transpiler, which allow
> us to move beyond the AMD/CJS schism right now.
>
>
> --
> Dr. Axel Rauschmayer
> axel at rauschma.de
> rauschma.de
>
>
>
>
> _______________________________________________
> 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/20140609/dd53b939/attachment.html>