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 <car...@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 <tos...@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 <car...@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 <a...@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
>>>> a...@rauschma.de
>>>> rauschma.de
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
