ES6 modules (sorry...)

[Rick Waldron]

On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf <calvin.metcalf at gmail.com>
wrote:

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

re:

  let { foo, bar } = import "library";

Ignoring the UnaryExpression ambiguity, what happens here:


// library.js
export const MAX_VALUE = 1023;


// program.js
let { MAX_VALUE } = import "library";
MAX_VALUE = 1;


Rick







>
> 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
>
> _______________________________________________
> 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/20140616/6a0f15c7/attachment.html>