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...

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/e0917b5c/attachment-0001.html>

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 and not by value...