Re: Import wildcards

2016-05-30 Thread Matthew Robb
On Sun, May 29, 2016 at 4:01 PM, Maël Nison wrote: > effectively exporting indirectly those symbols (since you need to parse > the imported module to know which symbols will be available). ​The difference with `export * from '...';` syntax is that it doesn't indirectly introduce named bindings

Re: Import wildcards

2016-05-29 Thread Logan Smyth
I think my biggest issue with this is that it seems like a solution in search of a problem. I can kind of see that you might end up with a setup where common property prefixes are common in the case of config files where you want many config options in one file. However, in the vast majority of JS

Re: Import wildcards

2016-05-29 Thread Maël Nison
I might be wrong, but the export * from '...' syntax seems to re-export every symbol from a given module, effectively exporting indirectly those symbols (since you need to parse the imported module to know which symbols will be available

Re: Import wildcards

2016-05-28 Thread Matthew Robb
Not exactly. To export a binding it must be declared in scope somewhere which means it's statically analyzable within a given file. On May 28, 2016 9:49 AM, "Maël Nison" wrote: > I see, but unless I'm mistaken, the same issue occurs with the export * > from '...' syntax, right ? > > Le ven. 27 ma

Re: Import wildcards

2016-05-28 Thread Maël Nison
I see, but unless I'm mistaken, the same issue occurs with the export * from '...' syntax, right ? Le ven. 27 mai 2016 à 16:06, Kevin Smith a écrit : > With this syntax, you would not be able to statically tell whether a > particular variable name (e.g. API_FOO) is bound to a module import, > wi

Re: Import wildcards

2016-05-27 Thread Kevin Smith
With this syntax, you would not be able to statically tell whether a particular variable name (e.g. API_FOO) is bound to a module import, without also analyzing the dependencies (and perhaps their dependencies). These considerations killed the original "import all" syntax. (`import * from 'foobar'

Import wildcards

2016-05-27 Thread Maël Nison
Hi, In about every project I have, I write a file or two with this form: export let API_USERNAME = `name` export let API_TOKEN = `token` // etc Most of the time, when I need one of those variables somewhere, I also need the other. It might be burdensome, since I end up with something

Re: Import wildcards on the right side of the statement

2016-04-22 Thread Francisco Méndez Vilas
Hi Caridy, Thank you very much for your feedback. I will definitely go for the loader option. Cheers, Francisco El jue., 21 abr. 2016 a las 18:22, Caridy Patiño () escribió: > Hey Francisco > > There is nothing in the spec that prevent you from doing `import * from > 'shared/features/**/reducer

Re: Re: Import wildcards on the right side of the statement

2016-04-21 Thread Alican Çubukçuoğlu
I think `import` should be as dumb as possible and you should look for another way to do this and it is probably [WHATWG Loader]( https://github.com/whatwg/loader). Another problem is that you are supposed to point to a single module when you `import` and you point to multiple modules when you glo

Re: Import wildcards on the right side of the statement

2016-04-21 Thread Caridy Patiño
Hey Francisco There is nothing in the spec that prevent you from doing `import * from 'shared/features/**/reducers';`, the module identifier is just a literal. What to do with it is not described by 262. As for "from many", you can easily do that with a loader without having to introduce new g

Re: Import wildcards on the right side of the statement

2016-04-21 Thread Matthew Robb
This could be made to work as a feature in the server side. Basically you are asking the server to give you a virtual rollup module where the body is basically just a bunch of export * from 'x';. Where even that gets sticky though is when dealing with default exports. On Apr 21, 2016 7:11 AM, "kdex

Re: Import wildcards on the right side of the statement

2016-04-21 Thread kdex
A browser couldn't possibly resolve globs at runtime without you providing some additional information to the runtime environment, so I don't see how this could be implemented. It's not really about browsers, anyway; the ES environment knows nothing about files, either. (meaning that `require` i

Re: Import wildcards on the right side of the statement

2016-04-21 Thread ziyunfei
Don't forget that JavaScript can run in the browsers.___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Import wildcards on the right side of the statement

2016-04-21 Thread Francisco Méndez Vilas
Hi all, This is my very first proposal here, so please let me know if i'm not following some rules. I want to make a proposal around the "import" syntax, it is, for instance: import * from 'shared/features/**/reducers'; or import * from many 'shared/features/**/reducers'; This came to my mind