Import wildcards

Maël Nison nison.mael at gmail.com
Sat May 28 13:48:51 UTC 2016


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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160528/a9db5ab9/attachment.html>


More information about the es-discuss mailing list