Just use JSHint.
-----Original Message-----
From: es-discuss [mailto:[email protected]] On Behalf Of Brian Di
Palma
Sent: Wednesday, October 8, 2014 12:29
To: caridy
Cc: [email protected]
Subject: Re: Importing global into modules.
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 <[email protected]> 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 <[email protected]> wrote:
>
>>> On Wed, Oct 8, 2014 at 4:38 PM, caridy <[email protected]> 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
>>>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
