Rationale for dropping ModuleImport syntax?

[Caridy Patino]

Chris, the number of exports is not relevant, and in fact, there is no way
to export all members in one go, which aligns well with the proposal to
remove the way to import an object with all members. check the consumers of
the `uikit` module, and count how many of those exported methods are used
in a single module. In fact, this repo is consistent with what we have been
saying. If you look at
https://github.com/toshok/pirouette/blob/master/bindings/objc.js, it uses
`module objc_internal from '@objc_internal';`, then it uses 5 methods
exported by that module, which should not be a pain to declare them
explicit as imports.


On Mon, Jun 9, 2014 at 12:18 PM, Chris Toshok <toshok at gmail.com> wrote:

> Pirouette also has many exports per module for its bindings:
>
> E.g.
> https://github.com/toshok/pirouette/blob/master/bindings/uikit.js.
>
> I use both import-{}-from (with many imported bindings) and module-from
> forms, tending toward the former in framework code and the latter in
> application code.
>
> The fact that the both forms can be accommodated from a single export form
> is the key for me.
>
> -c
>
> On Jun 9, 2014, at 8:36 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140609/09b6f17a/attachment-0001.html>