I might be wrong, but the export * from '...' <http://www.ecma-international.org/ecma-262/6.0/#sec-exports> 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). This syntax is quite valuable for configuration files, since you can "export *" from a base configuration, then overwrite specific symbols by using the usual "export MY_SYMBOL" syntax.
Le sam. 28 mai 2016 à 17:06, Matthew Robb <[email protected]> a écrit : > 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" <[email protected]> wrote: > >> 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 <[email protected]> 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, >>> without also analyzing the dependencies (and perhaps their dependencies). >>> These considerations killed the original "import all" syntax. (`import * >>> from 'foobar'`); >>> >>> If repitition is an issue, use the namespace import form. >>> >>> import * as constants from 'config'; >>> >>> >>> On Fri, May 27, 2016 at 10:00 AM Maël Nison <[email protected]> >>> wrote: >>> >>>> 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 >>>> similar to this: >>>> >>>> import { API_USERNAME } from 'config'; >>>> import { API_TOKEN } from 'config'; >>>> // etc >>>> >>>> Of course, I can import all of these token in a single line, but it >>>> doesn't help readability when there is a lot of entries (we all know that >>>> configuration files always end up with a fair number of variables - and >>>> let's not talk about parsers and similar). Plus, it's not very fun to >>>> explicitely write all these names when I just want to tell the engine that >>>> I will need everything similar, pretty please. >>>> >>>> Now as for the request: what would you think about adding a new syntax >>>> -nothing too fancy- to import all the symbols that match a *static >>>> *pattern? >>>> In the spirit of the `export * from ...` syntax, I feel like the following >>>> could be interesting: >>>> >>>> import { API_* } from 'config'; >>>> >>>> As for the bad part: there really isn't, actually. This syntax is >>>> familiar with every developer that used globing before, and gives just >>>> enough insight to someone looking at the source code to understand that a >>>> variable named `API_SOMETHING` has been imported from a parent module. >>>> Linters would also be able to help in this regard, since they would just >>>> have to blacklist declaring variables that would conflict with an import >>>> prefix. >>>> >>>> Any thoughts ? >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
