e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7


On Mon, Jun 16, 2014 at 1:01 PM, C. Scott Ananian <ecmascript at cscott.net>
wrote:

> On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
> <calvin.metcalf at gmail.com> wrote:
> > They curly braces only look like destructuring if you keep the name the
> > same, when imported with a different name it's a slightly different
> syntax,
> > {oldname as newname} not {oldname: newname}, also as it currently stands
>
> I wish that the authors of the module spec would accept that "object
> as module" is something JS authors have gotten used to.  It's rather
> nice that we don't have to add another "module" type to our mental
> model.  I understand that the spec authors want to insert some magic
> mechanisms so that cyclic dependencies "just work", but that shouldn't
> require us to invalidate our simple mental model for the common case.
>
> Using destructuring syntax for imports would be a *good thing*.  It
> builds on our existing understanding of JS constructs, instead of
> adding more gratuitously different things to learn.
>
> Similarly, I like the proposal floated here on es-discuss that reuses
> the same syntax for "default exports", so that the user doesn't have
> to know whether the module author did a default export of an single
> object, or used exports of named functions.  The syntax should help
> the developer by papering over these differences so that destructuring
> and uses were consistent.  Sure, there would be some subtle
> differences under-the-covers regarding the type of the module object
> and how the destructuring assignment was implemented, but the syntax
> shouldn't make the user stumble over these.
>   --scott
>



-- 
-Calvin W. Metcalf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140616/56f5c0b9/attachment.html>

e.g. something like https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7