ES6 modules (sorry...)

[Matthew Robb]

- Matthew Robb


On Mon, Jun 16, 2014 at 11:42 AM, C. Scott Ananian <ecmascript at cscott.net>
wrote:

> On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb <matthewwrobb at gmail.com>
> wrote:
> > My argument is that you can keep everything the same as it is now but
> change
> > the syntax to not use curlies and avoid the confusing similarity to
> > destructuring. You could use `(a,b,c)` or `<a,b,c>` and it would all
> > continue working as it does but be less confusing.
>
> And (just restating my position), I'm saying that using a new
> arbitrary punctuation here would be *more* confusing, since 99% of the
> time the behavior will be exactly as if it were destructuring (ie, the
> module isn't going to do any funny mutable binding tricks).  If it's a
> "magic destructuring" at least make it *look* like a destructuring
> (ie, no crazy "as" keywords), so that developers don't have to learn
> where the magic hides unless it is necessary.
>   --scott


​So it seems like we agree. So long as ES6 module syntax and semantics are
1:1 with destructuring then label it so. If the previous assertion is true
then WHAT is being destructured? Certainly not the default export rather
instead it would be the Module instance you are destructuring. This makes
`import blah from "blah";` no longer make sense. I think this is the core
of the confusion and if we want it to be destructuring then I think it
needs resolved so that whatever is imported without curlies represents an
object that contains the named exports. Unfortunately the only two clean
ways to do this would be to have single export ONLY or to have no default
export (I could be wrong but I don't think so).

The alternative is to accept that it's NOT destructuring and do whatever
needs to be done to reduce the confusion between them. The benefit of this
approach is you still get named exports and you still get single export via
default exports. This could be achieved by making default import more
explicit or by making named imports stand out more from destructuring.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140616/b8da1a3e/attachment.html>