Sorry, I meant free variables inside the module.

The reason why I originally started this thread was to ask if importing
global references or the global would be a way of adding static checks
of free variables in modules.

You are right that you can't check properties of the global.

Hence the suggestions to either import the global and require
module code to prepend "global" before accessing global properties.


import global from "@global";

global.myGlobalFunction(); //may not exist just like normal global code.


In this case only "global" is checked for existence so this should
not require special logic in the module system.

The other suggestion was to process an import global as a special
module which does not have any binding checks performed on it.


import {myGlobalFunction, MyPolyfilledConstructor} from "@global";

myGlobalFunction(); //may not exist just like normal global code.


Either of the two approaches allows an easy upgrade path for ES5 code
to ES6 modules and should allow the introduction of a ban on free
variables in modules.

I was curious if a ban on free variables in modules was worth considering
and any of the approaches outlined above were feasible.

B.


On Wed, Oct 8, 2014 at 5:15 PM, caridy <caridy at gmail.com> wrote:
> what do you mean by:
>
>> If the desire was there importing the global would also allow static
>> errors on free variables.
>
>
> If we ever decide to allow importing a reference to global from a module, it has to be a named import, and therefore, no static analysis can be applied to its members (since it is a shared, mutable object), what's the benefit then? ergonomic? I don't think so.
>
> /caridy
>
> On Oct 8, 2014, at 11:55 AM, Brian Di Palma <offler at gmail.com> wrote:
>
>>> On Wed, Oct 8, 2014 at 4:38 PM, caridy <caridy at gmail.com> wrote:
>>> Brian, my point is that using import to get access to `global` (as you suggested) is confusing due to the nature of the import, remember the contract: to import something, someone else has to export it first :)
>>
>> The JS environment exports the global object.
>> I don't think many developers will find code like that confusing and
>> it's easy to learn and understand.
>> It's just as complex as Reflect.global.
>>
>>> Aside from that, we don't want to have a exclusive way of accessing globals for modules, they should be accessible (as reflective) from everywhere.
>>
>> It doesn't preclude Reflect.global, it's simply an idiomatic way to
>> access the global in modules.
>>
>> I foresee a lot of
>>
>> const global = Reflect.global;
>>
>> at the top of modules in years to come.
>>
>> If the desire was there importing the global would also allow static
>> errors on free variables.
>>
>>> /caridy
>>>
>

Sorry, I meant free variables inside the module.

The reason why I originally started this thread was to ask if importing
global references or the global would be a way of adding static checks
of free variables in modules.

You are right that you can't check properties of the global.

Hence the suggestions to either import the global and require
module code to prepend "global" before accessing global properties.

```js
import global from "@global";

global.myGlobalFunction(); //may not exist just like normal global code.
```

In this case only "global" is checked for existence so this should
not require special logic in the module system.

The other suggestion was to process an import global as a special
module which does not have any binding checks performed on it.

```js
import {myGlobalFunction, MyPolyfilledConstructor} from "@global";

myGlobalFunction(); //may not exist just like normal global code.
```

Either of the two approaches allows an easy upgrade path for ES5 code
to ES6 modules and should allow the introduction of a ban on free
variables in modules.

I was curious if a ban on free variables in modules was worth considering
and any of the approaches outlined above were feasible.