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
