Also, @Yehuda Katz <wycats at gmail.com> argued that `module` is a common
variable name (QUnit uses it) and reserving it is a non starter.

`import {thisModule as yourName} from '@moduleMeta'` (bike shedding TBD) is
a promising path forward.

On Mon Jun 09 2014 at 11:28:59 AM, Matthew Robb <matthewwrobb at gmail.com>
wrote:

> Because that assumes everyone needs it all the time. The nice thing about
> it being opt-in is that when it comes time to use it a person has to first
> learn the entry point and from then on be explicit about it. I prefer
> explicitness 99% of the time because it's easier to track down for new
> contributors to a code base etc.
>
>
> - Matthew Robb
>
>
> On Mon, Jun 9, 2014 at 8:24 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>
>>
>> I guess it just seems odd to me that we HAVE a system in place now for
>>> importing "stuff" into a Program with an author defined local identifier
>>> name and we're discussing magic like using this or module. Just make it
>>> another thing the author imports inside their own module? ``` import meta
>>> from "./@meta"; ``` or something in the ballpark. Let's use the system
>>> we're creating to our advantage.
>>>
>>>
>> That's true, but I don't understand why we can't just have (to use your
>> example):
>>
>>     import module from "./@meta";
>>
>> As an *implicit* import within each module.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140609/68ffefbc/attachment.html>

Also,  Yehuda Katz argued that `module` is a common variable name (QUnit uses it) and reserving it is a non starter.

`import {thisModule as yourName} from '@moduleMeta'` (bike shedding TBD) is
a promising path forward.