Rationale for dropping ModuleImport syntax?

Matthew Robb matthewwrobb at gmail.com
Wed Jun 11 13:25:39 PDT 2014


​​I have been working extensively with modules in a project that will be
going live this year. I am using traceur and I find myself often doing the
following:

 module fs from "fs";
> var { readFile } = fs;

​OR

> ​import { readFile as _readFile } from "fs";
>
​var
> ​readFile = _readFile;​
>

​​It's partially due to the way module's get transpiled, if I were to just
do `import { readFile } from "fs"` then every reference to readFile in the
source ends up looking like `deps[0]["readFile"]()`​​

Transpile aside, I don't want that performance concern. Most of the time I
want a real solid reference and the only way to get it as the spec stands
is to import something and then cache it locally. Isn't that kind of crazy?



- Matthew Robb


On Wed, Jun 11, 2014 at 12:54 PM, C. Scott Ananian <ecmascript at cscott.net>
wrote:

> On Wed, Jun 11, 2014 at 3:41 PM, Kevin Smith <zenparsing at gmail.com> wrote:
> > Well, you're assuming exactly the state of affairs that this thread is
> > questioning...  The fact that the threat of changing things to this
> degree
> > has dredged up such polarized opinions should indicate that we ought to
> be
> > leaving things alone.
>
> ...or that the compromise is making nobody happy, in which case
> perhaps we've be better off with a simpler design which at least
> *some* people really liked?
>
> I don't know.  My personal opinion is that the modules stuff still
> feels like the odd duck which is being shoved into ES6 even though
> it's not quite ready yet.  But I'm hoping it all works out in the
> end...
>   --scott
> _______________________________________________
> 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/20140611/bdcb1c81/attachment.html>


More information about the es-discuss mailing list