e.g. something like https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
On Mon, Jun 16, 2014 at 1:01 PM, C. Scott Ananian <[email protected]> wrote: > On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf > <[email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
