Would these guarantees not enable more features to be added to the language?
I mean if they are worthless guarantees then fair enough it's not worth considering. On Wed, Oct 8, 2014 at 5:37 PM, Domenic Denicola <[email protected]> wrote: > 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
