Brian Di Palma (2014-10-03T18:17:49.000Z)
The recent thread on throwing errors on mutating immutable bindings
touched upon the fact that there is no static unresolvable reference
rejection in modules.
I was wondering if that was down to needing to allow access to
properties set on the global object?

If that's the case why could you not just import the global into a module scope?
Just like you import module meta data the module system could have a
way of providing you the global object if you import it.
That would mean that any reference that is accessed via the global
import can't be checked but every other one can.

Something like


import * as global from "@global";

const myValue = global.myGlobalFunction(); //Special won't be checked
can be mutated by everyone, big red flag in code reviews.

function test() {
    x = 10; //Static error, we know this is not an access to a global
x as it must be accessed via global.
}


Could this work?

B.
domenic at domenicdenicola.com (2014-10-15T18:54:35.826Z)
The recent thread on throwing errors on mutating immutable bindings
touched upon the fact that there is no static unresolvable reference
rejection in modules.
I was wondering if that was down to needing to allow access to
properties set on the global object?

If that's the case why could you not just import the global into a module scope?
Just like you import module meta data the module system could have a
way of providing you the global object if you import it.
That would mean that any reference that is accessed via the global
import can't be checked but every other one can.

Something like

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

const myValue = global.myGlobalFunction(); //Special won't be checked can be mutated by everyone, big red flag in code reviews.

function test() {
    x = 10; //Static error, we know this is not an access to a global x as it must be accessed via global.
}
```

Could this work?