ES6 modules (sorry...)

[Rick Waldron]

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

>
>
> A good question Rick, I sketched that out pretty quickly earlier today.
>  It did take me a while to remember that modules are the ONE place where
> strings are by reference an not by value...
>

It's more than that—if I specify an export of a specific binding form (in
this case `const`, whether it's a primitive string value or otherwise),
then user code shouldn't be able to change the meaning. My const should
only be a const, but your design has the surface appearance of permitting
that const to become a let binding.

Rick



> On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron <waldron.rick at gmail.com>
> wrote:
>
>>
>>
>>
>> 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
>>>
>>>
>>
>
>
> --
> -Calvin W. Metcalf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140616/c3d973f9/attachment-0001.html>