Rationale for dropping ModuleImport syntax?

[Chris Toshok]

That particular use of module-from is a little special. "@objc_internal" is a native module. Once ejs supports enumerating multiple exports from native modules I'll be switching that to an import-{}-from.

An example of use would be my toy test applications that consume the modules:

https://github.com/toshok/echo-js/blob/master/test/osx-test/helloosx.js

This uses the import-{}-from syntax and as you can see it's getting rather long for appkit (and it only has a window, a button, and a table view).  In my other toy apps I've switched exclusively to module-from to keep things from getting out of hand while I work. I thought I'd also added an iOS test to the git repo, but apparently I haven't - will rectify today.

I would also suggest that supporting both forms allows for better early prototyping (module-from) when you don't know exactly what you'll be pulling in, with the optional upgrade to potentially faster (definitely faster in ejs currently) import-{}-from form later when your code matures, all while maintaining easy static checking.

> On Jun 9, 2014, at 9:26 AM, Caridy Patino <caridy at gmail.com> wrote:
> 
> 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/f11ebe8d/attachment.html>