Import wildcards

Matthew Robb matthewwrobb at gmail.com
Sat May 28 15:06:58 UTC 2016


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" <nison.mael at gmail.com> 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 <zenparsing at gmail.com> 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 <nison.mael at gmail.com> 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
>>> 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/20160528/9fce147d/attachment.html>


More information about the es-discuss mailing list