forbes at lindesay.co.uk (2014-06-10T11:55:15.587Z)
"esparse" used to have a module which exported a huge list of things, and for the same reason I believe. Basically there's an "AST" module which exports a huge list of AST node-type classes. That module is then exported to the public interface. https://github.com/zenparsing/esparse/blob/53566066a9d1780bb27f73d208160595e2e0bb47/src/AST.js I moved away from this approach only for performance reasons (basically to avoid inheritance) because I'm optimizing hot, transpiled ES6 -to-ES5 code. Were it not for the (somewhat ugly) performance optimization, I would have left the multi-export design.
"esparse" used to have a module which exported a huge list of things, and for the same reason I believe. Basically there's an "AST" module which exports a huge list of AST node-type classes. That module is then exported to the public interface. https://github.com/zenparsing/esparse/blob/53566066a9d1780bb27f73d208160595e2e0bb47/src/AST.js I moved away from this approach only for performance reasons (basically to avoid inheritance) because I'm optimizing hot, transpiled ES6 -to-ES5 code. Were it not for the (somewhat ugly) performance optimization, I would have left the multi-export design. On Mon, Jun 9, 2014 at 11:41 AM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote: > Traceur definitely has a lot of exports in a single module. > > > https://github.com/google/traceur-compiler/blob/master/src/syntax/Parser.js#L15 > > We do not however, use the `module` form since we want to get rid of the > extra Get (which deopts switch statements in some engines). > > On Mon Jun 09 2014 at 11:36:58 AM, Caridy Patino <caridy at gmail.com> wrote: > >> My perspective here is that there are not too many modules (in nodejs) >> that rely on more than a handful of exports from a particular module, we >> are actively working on validating this using esprima in a large set of npm >> modules. If this is true, we should be just fine with specific imports, and >> for the edge cases, an imperative form should be sufficient. >> >> For now, I will ask you all to try to find a modules that are using too >> many exported methods from one of its imported modules, you will be suprise >> how hard it is too find those. >> >> >> /caridy >> >> >> On Mon, Jun 9, 2014 at 11:27 AM, Axel Rauschmayer <axel at rauschma.de> >> wrote: >> >>> As an aside, it is yet to be seen whether the "default" export thing is >>> the best way, or the bad part itself. We don't have the real world >>> experience yet to answer that. >>> >>> >>> I’d even argue that they led to the predicament that we are currently in. >>> >>> If the default export didn’t look like “the module”, things would, in my >>> opinion, be easier to understand: >>> >>> ```js >>> import _ from "Underscore"; >>> import { flatten, union } from "Underscore"; >>> import default someFunction from "single_function_module"; >>> ``` >>> >>> -- >>> Dr. Axel Rauschmayer >>> axel at rauschma.de >>> rauschma.de >>> >>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > 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/20140609/242d81a9/attachment-0001.html>