> 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
>

> 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

```js
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.