On Thu, Jun 12, 2014 at 6:37 PM, Chris Toshok <[email protected]> wrote: > On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma <[email protected]> wrote: >> >> Is there anything preventing the addition of a "ModuleImport" like >> affordance at a later stage (e.g. ES7)? > > > ModuleImport is the only way (in syntax) to achieve CommonJS `require` > behavior on the consumer-side when a module author exclusively uses multiple > exports. > > Its lack will force existing module maintainers to export as small a set as > possible - likely either a single identifier - so that they can service the > existing identifier-as-namespace convention CommonJS forces. > > Given that there's no real syntactic difference between single identifier > export and default export, I would imagine default export would win since > then you get: `import _ from 'underscore'` instead of import { _ } from > 'underscore'`. >
I can see that being a valid path for certain modules to take. I'm not sure large utility packages will be as prevelant in future though. Once we have a standard module system it seems just as likely that these packages might break apart somewhat. There seems no reason to load all of underscore into a module for just one or two functions. The underscore web page itself divides the functions http://underscorejs.org/ We should also be wary of building cases on code from Parsers, I believe the unstructured switch statement was designed for parsers. It didn't turn out to be an optimal design for routine programming though. I was more wondering if there was anything preventing a module import statement from being added later, if it was found to be a requirement. I can't see any reason why it couldn't, that would also allow time for bikeshedding the syntax. >> Related to some other comments made in this thread, I think static >> verification errors are a great idea. >> I'd also like to echo the comments that ES6 modules seem well >> designed, looking forward to native implementations. > > > I definitely agree. I think the semantics and specification are awesome. > And having syntax at all is *huge* for tooling and aot/static compilers. > > The ModuleImport syntax can be bikeshedded until the cows come home. It's > not important (to me). What's important is that there is syntax to get at > its functionality, not imperative code. > The imperative code given as an alternative is ugly, it probably won't gain many users. > IMO the only real issue is the tight coupling between syntax used to import > and syntax used to export. Why as a module consumer should the module > author's choice dictate which syntax I'm forced to use? And why as a module > author should the syntax my users want to use dictate how I have to export > my module? If syntaxes were decoupled, ModuleImport could go away and we > wouldn't lose the functionality, it would simply be `import _ from > 'underscore'`. I like the idea but I can't imagine many people would welcome yet more changes to ES modules. > > I don't think it's outlandish, the possibility that a large enough portion > of the community will decide on a single import syntax as "best", and > network effects will result in it going from "best" to "only". > > -c _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
