domenic at domenicdenicola.com (2014-10-15T18:59:30.152Z)
Does that mean that anything that is imported is frozen?
You can't add properties to any binding you import?
I've never heard of this restriction before.
If that restriction doesn't exist then I'm not sure I see what issue this causes
```js
import { global } from this module;
```
global in this case is an object and I was under the impression that you
could add and remove properties to an object if you imported one.
Providing an idiomatic way for modules to access the global seems good
ergonomics.
Does that mean that anything that is imported is frozen? You can't add properties to any binding you import? I've never heard of this restriction before. If that restriction doesn't exist then I'm not sure I see what issue this causes import { global } from this module; global in this case is an object and I was under the impression that you could add and remove properties to an object if you imported one. Providing an idiomatic way for modules to access the global seems good ergonomics. On Wed, Oct 8, 2014 at 4:00 PM, caridy <caridy at gmail.com> wrote: > Guys, anything that you import is going to be subject to the binding process, they are immutable values. In the other hand, Reflect.global is just the new global for scripts and modules, plain and simple. > > Today, many libraries are relying on `new Function()` to artificially access global, and that's wont work with CSP, therefore we need to provide a reliable way to access global from anywhere, not only from modules. > > /caridy > > On Oct 8, 2014, at 10:34 AM, Brian Di Palma <offler at gmail.com> wrote: > >>> On Wed, Oct 8, 2014 at 3:21 PM, caridy <caridy at gmail.com> wrote: >>> var myGlobalFunction = Reflect.global.myGlobalFunction; >>> >>> note: you can't use import for global due to the nature of the binding process when importing members or namespaces. >> >> I find >> >> import global from "@global"; >> >> global.myGlobalFunction(42); >> >> more readable. >> >> If we can import module meta information why not import the global object too? >> The global should always exist so the binding checks will work, it's a >> module with a default export. >> >> Accessing any global property is via that object. >> >> No need to allow random identifiers floating around modules. >> >> B. >> >>> On Oct 8, 2014, at 9:57 AM, Brian Di Palma <offler at gmail.com> wrote: >>> >>>> On Wed, Oct 8, 2014 at 2:51 PM, caridy <caridy at gmail.com> wrote: >>>>> last time we discussed this, the conclusion was that `Reflect.global` is the way to go. more details here: >>>>> https://gist.github.com/ericf/a7b40bf8324cd1f5dc73#how-do-we-access-the-global-object-within-a-module >>>>> >>>>> once realms landed, it will reflect `realm.global`. >>>> >>>> I guess >>>> >>>> import {myGlobalFunction, MyPolyfilledConstructor} from Reflect.global; >>>> >>>> then? >>>> >>>>> ./caridy >>>>> >>>>> On Oct 8, 2014, at 8:52 AM, Andreas Rossberg <rossberg at google.com> wrote: >>>>> >>>>>> On 8 October 2014 14:11, Brian Di Palma <offler at gmail.com> wrote: >>>>>>> I didn't realize how limited in power these fast parsers actually >>>>>>> were, they are basically lexers. >>>>>> >>>>>> No, that's not correct. They have to perform a full syntax check. That >>>>>> does not imply binding analysis, though, which is usually regarded >>>>>> part of the static semantics of a language, not its (context-free) >>>>>> syntax. (More by accident than by design, JavaScript so far didn't >>>>>> have much of a static semantics -- at least none that would rule out >>>>>> many programs, i.e., induce compile-time errors. Hence engines could >>>>>> get away with lazy compilation so well.) >>>>>> >>>>>>> I'm doubtful that it would have a significant user perceivable effect though. >>>>>>> I imagine modern browser engines perform a lot of work in parallel >>>>>>> where they can. >>>>>> >>>>>> Unfortunately, parallelism doesn't help here, since this is all about >>>>>> the _initial_ parse (of every source), which has to happen before >>>>>> anything else, and so directly affects start-up times. >>>>>> >>>>>>> One way around having an impact on current workloads is to only parse >>>>>>> in this fashion for modules. >>>>>> >>>>>> Yes, see the earlier posts by Dave an myself. Didn't happen, though. >>>>>> >>>>>>> As these modules would be stand alone fast parsing should be >>>>>>> embarrassingly parallel. >>>>>> >>>>>> You can indeed parallelise parsing and checking of separate modules, >>>>>> but each individual task would still take longer, so there would still >>>>>> have been a potential overall cost. >>>>>> >>>>>>> Yes hoisting is another complication, more bookkeeping, it will >>>>>>> probably delay when an error can be raised. >>>>>>> But would you not have to deal with it anyway? Can you not export a >>>>>>> hoisted function? >>>>>> >>>>>> Yes, as I said, recursive scoping (a.k.a. "hoisting") is neither a new >>>>>> nor a significant problem. >>>>>> >>>>>>> Fully closed modules are as you said are probably too tedious - that >>>>>>> can be dropped. >>>>>>> It's more about making modules closed against user defined state as >>>>>>> opposed to system defined state. >>>>>> >>>>>> Yes, but unfortunately, you cannot distinguish between the two in >>>>>> JavaScript -- globals, monkey patching, and all that lovely stuff. >>>>>> >>>>>> /Andreas >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> es-discuss at mozilla.org >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>> >