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.r...@gmail.com> wrote: > > > > On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf <calvin.metc...@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 <ecmascr...@cscott.net> >> wrote: >> >>> On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf >>> <calvin.metc...@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@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -- -Calvin W. Metcalf
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss